<%BANNER%>

Design and implementation of an intelligent primitive driver

University of Florida Institutional Repository
xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20110109_AAAAYK INGEST_TIME 2011-01-09T22:45:06Z PACKAGE UFE0001146_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 1368 DFID F20110109_AACPGM ORIGIN DEPOSITOR PATH vinch_p_Page_79.txt GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
fe4ad5bbc5189b6b52c2fbd239388908
SHA-1
e0a70c32d878844ffb81ce4b4b58a81c97416377
123440 F20110109_AACPBP vinch_p_Page_73.jpg
f3b5bb26bdee27af051dd29d6e46b46a
7f9e00c9cf2cf99a5c8925094c9ffce6fdd8348b
15001 F20110109_AACOZP vinch_p_Page_34.jp2
9879c66b828b17d6a84f0c8c6d3eda4a
453b29b5011dbc32d0da35f61ba642b644b9860c
162296 F20110109_AACOUS vinch_p_Page_47.jpg
f6a08b538b87d14b53c57b68fc215919
e71a95f88f29585ce7ebdd06dc418bef9a8cb53f
1053954 F20110109_AACOPU vinch_p_Page_82.tif
00c6331a80cd3406a9717d4e5261bebb
b8470e03471df98a98d1dc5ebc10d75a20b2dc33
2197 F20110109_AACPGN vinch_p_Page_80.txt
0b899902d1bddc7fa47ec5065316d699
794fa55645396e847af4fcd83ca85611e8bd8650
97760 F20110109_AACPBQ vinch_p_Page_75.jpg
eecc467cae46087b2af71a4f0de98fd3
00268d684d96d2435a280ac3f617b681728a574e
87099 F20110109_AACOZQ vinch_p_Page_52.jp2
d537fd353e89eb9e9620390cb3d9153d
1f4ebd138fb5b3bb6e823a5a84704e37f90bdd98
665 F20110109_AACOUT vinch_p_Page_71.txt
b6ea46fc352cffed05153526f348970d
ada7d9608cae7a37080b3af1de1b0f4f2cdeb451
25674 F20110109_AACOPV vinch_p_Page_05.QC.jpg
d897a97771b68abaf3a02e88abcefe92
30311e6b905dbc76b67fac882a80a4a31f42d04b
2257733 F20110109_AACPGO vinch_p.pdf
491507cb417b676e61bbd20fac1e7f77
6ed6eb18c666b13e9ab7fbd981d043164bf945e7
154449 F20110109_AACPBR vinch_p_Page_77.jpg
c8044fd94516ecb2ce9a8e5203cb5e9d
35036bdb94c87203381c8643bc91504664400504
F20110109_AACOZR vinch_p_Page_22.tif
28d128595835339d5a4661c0a5df1ad1
0610452261316299ff0efd298f54fa2a547b85c3
25271604 F20110109_AACOUU vinch_p_Page_10.tif
3963afa33fe994c3b354601373daa9f2
c3444aa909874135b38f905eac290b35def19e5a
15807 F20110109_AACOPW vinch_p_Page_72thm.jpg
25d0697b336efd136189ca74ac065bde
e5a2f9a7e6bcc8673e506bc4b8d4ca8d1c9821de
97764 F20110109_AACPGP UFE0001146_00001.mets FULL
4ad09826ba180f62f21ac5bac6026997
5feb308107d99b82fc4f54c53fc2eea142204142
88043 F20110109_AACPBS vinch_p_Page_78.jpg
75db1b73e094bb8aee8fd0cb3811093d
c75b47bd0a62f1ac11bc0690d7bf9cd75f9a8171
48541 F20110109_AACOZS vinch_p_Page_60.pro
6e41ce76b439c24c080569831f3b96f1
64cf862894d62e6e2b223f7cb7c4acc5be57ac51
1773 F20110109_AACOUV vinch_p_Page_43.txt
12ac08cb6e56e8302efbe0a9686c962c
fb491f3b0da9824226d4db040dd8e862bc1f9086
823607 F20110109_AACOPX vinch_p_Page_26.jp2
1434c9f47455dfa587af62c9bbedb812
fb04ecc3a83625b91970af8486599eecfc86bfc1
5485 F20110109_AACPGQ vinch_p_Page_02.QC.jpg
6e9b3922b1497f3ad20a04ae5e944a5a
26203aa5d8462c34571e443473d9ea94badfa758
198549 F20110109_AACPBT vinch_p_Page_79.jpg
9fceb61d014f42cb7ce4577962e3b5eb
47c27e79890be23241bd66d93edd77f900af2603
101517 F20110109_AACOZT vinch_p_Page_30.jp2
3ea9ff662ab30c880e921f635217ffb9
e066f51b414c6dd8a0fccf288f7079f102ca42ef
22523 F20110109_AACOUW vinch_p_Page_28.pro
476cc15126201f4fa00e0850f875ce4a
d003d6274571b66a25898bf358090005cd1a4deb
153304 F20110109_AACONA vinch_p_Page_27.jpg
18534df3f22eae565add08a07a163a14
59242cc3ddab3beae24663266dc87b37e42c6ed4
88206 F20110109_AACOPY vinch_p_Page_38.jp2
d491fca9c91037e681512c2e84bc0678
6a02c5387d94f0e81333e0492f9151ab636cf22b
3091 F20110109_AACPGR vinch_p_Page_02thm.jpg
a7dc62787b836e5063ac6113e4dc4426
3128ac6bcbdd1dcb85e003d55c7b2acf2e3fa206
108895 F20110109_AACPBU vinch_p_Page_81.jpg
8973c54af5337e291c3ee93d94e0539d
c59da9795a551e0e1687023222924c05831a0990
60951 F20110109_AACOZU vinch_p_Page_35.QC.jpg
42508c206542811d78232c8573ea3f32
f455eb54a70edc1ccc92798843e23039b9126bf0
F20110109_AACONB vinch_p_Page_66.tif
524333c7bb0b4d806d0f2a4b4a8b0e13
8bb6cc4bd4721f39f5e8cc8afff69237c9d3626a
127032 F20110109_AACOPZ vinch_p_Page_72.jpg
5c85c4dbf021a7e2939f242baedde074
4184e55b66d9c40433c95b99132f64f31f6a1e72
48681 F20110109_AACPGS vinch_p_Page_07thm.jpg
9abea692307a2f8884fd22acf695bb8b
af2ed163ac28147312e9195dc7f005a82af10437
136124 F20110109_AACPBV vinch_p_Page_84.jpg
0b39694ab48382e69c09d5329a1f25ad
d76013711fe89a0a0b43dc6bbb07894157c76bf5
38932 F20110109_AACOZV vinch_p_Page_11.pro
ec5dee39c045f46cd2c00334968cd4e9
b18a1f988a20c61c1b77124d184f643726d45b24
2002 F20110109_AACOUX vinch_p_Page_17.txt
da7b30198af2c5eb6dbb1ff325b5748a
2fa396983404ecad996b9207bf8675af302443ac
82902 F20110109_AACONC vinch_p_Page_19.jp2
4127183aedfd9a95e7eb1581a4a403c0
ed091b13bd38654e5635f6a6814d019523be4a8e
96199 F20110109_AACPGT vinch_p_Page_09.QC.jpg
727178a1dbda8cd960aabca4a070939b
2f276c7598b054d93918513d32c0bd2300c98072
5663 F20110109_AACPBW vinch_p_Page_02.jp2
3ddc79bb8a9a81a77de2019dfe9eb991
8842f43be0d298d52ee7fdc469da6049769cd161
F20110109_AACOZW vinch_p_Page_80.tif
8a772b40226e83912e25ca3eb1129d0f
f7ec4742406be14b6c3ceacaff0953b91afdb31e
F20110109_AACOSA vinch_p_Page_28.tif
493abfbef36cecc49bddff057398819b
49f0fa2b4a0f3bdf97a8792803fd56e6583491f9
75390 F20110109_AACOUY vinch_p_Page_28.QC.jpg
e5b519a7dc2658391750f985b0a4df90
4bd7a126066bb93cf36fa2ced0953c1f6d5b97ee
64910 F20110109_AACOND vinch_p_Page_39.QC.jpg
6de4429977243d23ce2cfd228afbfb5b
f387cc8beee156b3126dc499fdbc4394fd26fb11
76166 F20110109_AACPGU vinch_p_Page_10.QC.jpg
c00e7bf3c71d468df36363d2aa9e4724
9a10acf4b88cc18ae6260d8d4371a264592ec71c
1051980 F20110109_AACPBX vinch_p_Page_06.jp2
0fbd8286e2329206fb639dcec9de236d
3980fc889614ccde5c28ed6766950150f4fc246b
F20110109_AACOZX vinch_p_Page_71.tif
51b42ac39912f53f9bde7fff332a372a
53094b55e11a8e6de87581b57c937e668c965b47
F20110109_AACOSB vinch_p_Page_79.tif
f87ded1fc62ee6554d51f01e14f3a919
55e05e9b0ef9f24cff9e0e9b42bcd5d16eca900a
35144 F20110109_AACOUZ vinch_p_Page_46.QC.jpg
5cd489b5e80b80c9aebd9d2db4e6e319
6d667582cc505714c1ee34f76515519a0453f6c1
36695 F20110109_AACONE vinch_p_Page_75.QC.jpg
df18e74dde045215aa7f4b7fbc5eaed9
8c7ac4be94af4ad98246df6e7f5e2869a36128a6
41571 F20110109_AACPGV vinch_p_Page_10thm.jpg
e64bd34e28f0e233209e208c20e2e985
657f52964d5a0dfec367b1d35e71a8d29608e491
1051985 F20110109_AACPBY vinch_p_Page_09.jp2
39b0e0b7041ad5daf8d53b5e4d7a8b7d
349512a8bbbbd8e9660d7c1ddbae6135d3b927d6
F20110109_AACOZY vinch_p_Page_11.tif
366d9cc9b4b639bcb60d4c0a4161e98c
9ff450a23ba2333722b980bd36f23d94ecebb1f6
23607 F20110109_AACOSC vinch_p_Page_30thm.jpg
2b4204ec7ce86a392eede6749b3023e2
f980af5f77096853b265d93a0347b67bd05177df
22743 F20110109_AACONF vinch_p_Page_01.jp2
252390c161748f4adb1160ebe15815a4
1dc4449ba6c8506cf7416d5607804a8c78ee5e7e
61761 F20110109_AACPGW vinch_p_Page_11.QC.jpg
09395c80ddf379f1c565acdbe8472465
5c970832e8a988afbc35504eb6d909570cc1f3d9
80841 F20110109_AACPBZ vinch_p_Page_12.jp2
9a638d50bb259bce39d3873f46cc0234
ad74b24ccac010f701d54c7ec9e63aa1450f6b93
476539 F20110109_AACOZZ vinch_p_Page_65.jp2
350112c3d90c99e2f71b9fd5569d9cd7
6364609a13472a004085c2b2599e56c14a8bb7a0
67216 F20110109_AACOSD vinch_p_Page_32.QC.jpg
a3cce9643d2631bde42dec3c4227c3ce
f27a71e84618e583d5b033c3637f9a7aa8e41ae0
70787 F20110109_AACONG vinch_p_Page_57.QC.jpg
e3e5c9e25395ce4fa403193a01f8439e
64df86feaf3683394e5ea6eb0a22301fd65f8c61
3374 F20110109_AACOXA vinch_p_Page_83.txt
9e7ba4edf47f8065b584b222cad11028
bf60e9dc60bdf72932b00e4241bbde77e45b777b
20059 F20110109_AACPGX vinch_p_Page_12thm.jpg
f9e2e246a4360939f5d383395d9b2c3e
7a02d25a41a94f6663fa388cdf316079f600ad18
81049 F20110109_AACOSE vinch_p_Page_24.jp2
ea95da8f9970e2dba0e96b81e2a05514
9b42425e87f349dbc76075a2c1167e4f428843a0
F20110109_AACONH vinch_p_Page_23.tif
2c32be8d6ee56995b4bd00b810700c57
18b320ce9266b7212849b75355a47ddfbb0e322b
27227 F20110109_AACOXB vinch_p_Page_71.QC.jpg
c19fa7842fe3433a6236d95594c6ba19
c1b91b23125f512b2aa3cff6c2cbe1188224cc53
25390 F20110109_AACPGY vinch_p_Page_13thm.jpg
2f5321db53f20ae33cb90881d3faf0a4
77aed47a443619ccf97269d2b972f897bea86294
F20110109_AACPEA vinch_p_Page_76.tif
43ab0c6e4a31d731b2de7eca9856d950
1f40960221fe9b392cf14d23a957db97649a09b6
1930 F20110109_AACOSF vinch_p_Page_41.txt
e4accb84654348c8987d5bbdc0ebe721
a8ad7ff2315b1f04b05bdee7dd59b1b677f35d72
F20110109_AACONI vinch_p_Page_31.tif
79bb84255a8635ed0d6d13cbea33bb97
509edabc9bce83fd1d64dca007b8cd7928a3cecc
26303 F20110109_AACOXC vinch_p_Page_76.pro
53bb0a8a86c0e4439410532769c43974
4fa6caf41832a65e6828df1ac21da89d3d7d23d6
73886 F20110109_AACPGZ vinch_p_Page_14.QC.jpg
df7be77ebc1ec45f74dcea1e0aa0c607
b5275ffd09718f850b581287a8a3f72125049f94
F20110109_AACPEB vinch_p_Page_81.tif
e1481bd5efb84245a53f3928282b7e7d
ed2ef472a90f046bfa15cd851dea1bca6e3affea
F20110109_AACOSG vinch_p_Page_02.tif
2c7434bd1e6cb37a81c65075246c1022
8e97c665c769909acb30ab57bfe2bff0740bf03b
154729 F20110109_AACONJ vinch_p_Page_37.jpg
62cdff18afa8aeb14f8561c6a4dbd801
b98e3071989e52eb1c8f03e57ee61f7360caac73
105786 F20110109_AACOXD vinch_p_Page_07.QC.jpg
f571cfe059d3b52b55b59bbdc87858f6
2d91c5860e3747779be030278843c9b898e09a8f
91578 F20110109_AACPEC vinch_p_Page_07.pro
cfdf7d73d6ae09e68456bcb5d78e5632
0081fc378211fa6547f0596e6d35fe0620391a79
92873 F20110109_AACOSH vinch_p_Page_79.QC.jpg
24a1a2641689f3e70c8f865f086e63b3
fcfe5da96b88e476300b512da91c2cbfb4a3ccc5
16060 F20110109_AACONK vinch_p_Page_01.QC.jpg
11b3b2f065b6234a684f07243749700e
7cd311a1c9598d509c5944fd235f5a1157f394ee
F20110109_AACOXE vinch_p_Page_44.tif
0e4db86647bf5fda7cc007de0c670e38
2418a6432e866f900261119155c724ed794d2fbc
29013 F20110109_AACPED vinch_p_Page_08.pro
491a6bdf09df4a7961f14a6cb55d07ad
94453a8b7b4a0e2c492a800d4a41c0c1228834aa
F20110109_AACOSI vinch_p_Page_33.tif
48c3cc52790b6c565fa603ccdc64f2f1
348ad44d2ac8b43c49bd462eb2e9697683efbc6e
215 F20110109_AACONL vinch_p_Page_03.txt
00c92b0730eedc6f4729fad04b4b8b53
c433b4028af50a52eae7758a365ea2f431f8cc5f
1091 F20110109_AACOXF vinch_p_Page_55.txt
c80d1340a8bc86789b44e98e612e6cc8
6d3899f3b5e58ef840078a7e52de8bcb49173524
59327 F20110109_AACPEE vinch_p_Page_09.pro
270a72dd2efd6e7ef842cba1ec5158c3
40e67f87ded8a046e157254372594844019f3f8a
1713 F20110109_AACOSJ vinch_p_Page_40.txt
0afffd633f11aeae19c234f9de8ad2e5
1f51f0d92a7cc1d1ecab524ccf73ef051332744f
80045 F20110109_AACONM vinch_p_Page_17.QC.jpg
e688bf21baeb1a2e79903319f9f9a4e6
ae8eb2dad5d1da3da296b5c365a12b8d17b06189
60268 F20110109_AACOXG vinch_p_Page_48.QC.jpg
611c05fd984514077736638503497775
4280e2c5ed526c6697279bdac10979cd126d5338
48144 F20110109_AACPEF vinch_p_Page_15.pro
a739e17a99a228e68843e9083292cc0b
e3463e1b382c368ecf775bc5fa3f8796a569a892
63413 F20110109_AACOSK vinch_p_Page_40.QC.jpg
b5dd4dae74471c5cfb144f8ea70ed814
981f62729ec5ddcc810fb8b9c14ad36f84f96e23
F20110109_AACONN vinch_p_Page_13.tif
41be4ac2fd16cda0063cd34b19115cf1
08af4b314cb2999340ad35bd5f17ab622c92c66f
44543 F20110109_AACOXH vinch_p_Page_45.QC.jpg
71caf0ca2ce20b4324cbcb8ae41d585b
fc7d2db85b0bde2ac3b13a62f2811532566a64d7
191812 F20110109_AACOSL vinch_p_Page_50.jpg
510f38ab10437eaae5f9cd4e92bb5021
c2ceb6f8540c5ed896e35c7678d2d99a90ea21bc
208192 F20110109_AACONO vinch_p_Page_33.jpg
0e3c50e7af79fb622f50b3fa044b31fc
d97e2fc00d5ba3a9d198e2ac03adffc3d77aaff5
47826 F20110109_AACOXI vinch_p_Page_56thm.jpg
0ab1bbed23eec60fc7899beea2eaf515
6295d1f5d1e90db742a8f6e473a15b3c692955a4
49218 F20110109_AACPEG vinch_p_Page_16.pro
a1bc1947f6900fc79c095d63f10f2939
3fd1fee7e1922e3e1ac07a7da951376c11b5cbee
37398 F20110109_AACOSM vinch_p_Page_08thm.jpg
b3bc80d2746bc530d6bdc72290e5b47f
d56bcf17c94fd9fea5c5ac997bf576102738e6cb
42147 F20110109_AACONP vinch_p_Page_36.pro
2c23a4e47643289b457736a2b77476f4
46c6770f97a9b3ff36bec92b1561dbe5b88a1591
F20110109_AACOXJ vinch_p_Page_09.tif
816ccd655b138e4ff6f7e9683367b497
6d2d265be82efd69c5a855a2107f30d358d003ec
28516 F20110109_AACPEH vinch_p_Page_21.pro
59595f3be0d1c5da6783122db1ccb986
0801b0de1d11b90c75aafbb1f95bb31e3335cff4
F20110109_AACOSN vinch_p_Page_20.tif
607e563aa131e97b8da1151f7a3d25f2
83f3ce0b936acc54a9fe65b64d1aa40f1d7d9841
F20110109_AACOXK vinch_p_Page_74.tif
1cd876f9d90d349faac6455ad197d1e8
12de59b4ecbd4fa2bbb343a132aad9f7bbe223c5
25100 F20110109_AACPEI vinch_p_Page_25.pro
8e94ebfcee4ca2060ebcddd3a842ae0c
68143933533b2256cdf3b0d7ad6cd0763557d4b2
1019 F20110109_AACOSO vinch_p_Page_78.txt
762b1a1b90fe5b461838b681fa79e42b
fcad0518bddc41316881fd87f3b80bebf3cad7de
200367 F20110109_AACONQ vinch_p_Page_30.jpg
95cfc4eb7fdd542e52bed9a86818b02c
d866c95b76fb2be8fdf7dff10068dfb737a7feed
221996 F20110109_AACOXL vinch_p_Page_56.jpg
7e9995bc5cb2f7ee9ca5b52f8b61f886
b559059f5577dd68eceed3f3855ba23ec7536774
25944 F20110109_AACPEJ vinch_p_Page_27.pro
7636bd128c0ba4dbdd41927455f04984
32d1cb63fa068712c057086216cedaca98bfaa29
1172 F20110109_AACONR vinch_p_Page_53.txt
d67caae4bac2386ea0fbab017608bb00
1a9d2748f17993ab32b3f490f74efe29f41ee4aa
48070 F20110109_AACOXM vinch_p_Page_50.pro
a4065850c33f8325a2e95cc9f6dd149f
c90937237b3dae62f28837f142adc002f5f1e823
1725 F20110109_AACOSP vinch_p_Page_36.txt
743b4aabccd004c6e80e215f4aa353bf
2f251323ce4e8188032156d348f4a921df370943
31610 F20110109_AACPEK vinch_p_Page_31.pro
593564a3842989b6a177bba848dcda63
e8e2ae0e8beddf93cabcb04f67085a27dda79fcd
1997 F20110109_AACONS vinch_p_Page_38.txt
a2c08483edf2db878083e77f98ca7645
c1b5af11878e0995a28a160ea2df44259aa32df7
33263 F20110109_AACOXN vinch_p_Page_29.pro
4c60c0f81d2cd42590bcb6b16e71ff06
39e4117b345359712195d921aee6185ab48fb7e0
49720 F20110109_AACOSQ vinch_p_Page_67thm.jpg
23287ba9264b1111926dc4a3bdbc3538
16c5e1208f42cf95fe48f8f3cf619df02281b2cf
42674 F20110109_AACPEL vinch_p_Page_32.pro
2de1624ff5b9523fb32921d4c9b29e31
d020408d38950c0c809d9aff75ee919244f8d5c3
48082 F20110109_AACONT vinch_p_Page_23thm.jpg
14f090c56ed66b3495370e4bd3ded338
4f8f186135f81253b599252db4eca694e30a8c09
103426 F20110109_AACOXO vinch_p_Page_15.jp2
3d8c6b1e01722670d66fae4e3bd5bd90
8d260070a07ba62f7264af2f629733ebd2ca58d8
44847 F20110109_AACOSR vinch_p_Page_72.QC.jpg
881957750eaf707a9207ab72446df151
fb053fb777ec4e67b36df10ee31725800efd5308
48566 F20110109_AACPEM vinch_p_Page_33.pro
aca5ecefe41cb0f0b12f586ea39119a7
b11c362f2b9a0c8018f455891d05902101dfe3d5
1134 F20110109_AACONU vinch_p_Page_28.txt
d909d9d7c75defc945dc4c68b22c387a
9b8d752a10c69e58c1669b6b48a64fa5569c0631
11489 F20110109_AACOXP vinch_p_Page_03.jp2
4b21289489953c06282215c7590f3261
9c63621e758a1268c31a28609c1890f6df82ea06
64863 F20110109_AACOSS vinch_p_Page_08.QC.jpg
aff48b9fd3faf6864696b2681a324258
dc31957cf48a65b5e656e63b48648564cef69a24
5523 F20110109_AACPEN vinch_p_Page_34.pro
7172652d6de7c52bf2cc57dde32c3dff
0ef5512b1bd26287ee4fa31bc4695c9cbb85bb2b
13766 F20110109_AACONV vinch_p_Page_46.pro
4f61ab26e01c448a9384955fbb016194
e984ce4192727ace315636b279037d881f7ae814
78699 F20110109_AACOXQ vinch_p_Page_31.jp2
3b317c4ba1c75db02bd0acb4da930cda
52e0c1027ae87c1d5aede5549607039851518ef4
199611 F20110109_AACOST vinch_p_Page_15.jpg
1a69f33d5a33175649f11fe1a58590ef
30e9df2c6e7fafa1af2bad2422969e00e53fa304
37267 F20110109_AACPEO vinch_p_Page_35.pro
63d5edcf4ad4d3493d9a51bd2e67ff2c
dd9fb3764f8e1170eda82783cc0cf22682256bc0
90556 F20110109_AACONW vinch_p_Page_66.jp2
331c568b6bae361c730cf4d7147a90d5
c61d67fcccb5747f00d20e307707db00830c85eb
F20110109_AACOXR vinch_p_Page_56.tif
03866b80ff4ea70a933b1b66931aab90
38126cf1eda3a5ef79c83876a885b0a40f1c480a
82962 F20110109_AACOSU vinch_p_Page_26.QC.jpg
5da5db0b7260ca6ff1efffd931595bf4
cf6f92f6d214d83d73e9ebcccda00f3d6fab9576
43787 F20110109_AACPEP vinch_p_Page_38.pro
ea61aff83c8c0c7d8e66bd9dbfedcc74
e9408724aeed71364b653d1cecf7fe0a1a0c667b
52568 F20110109_AACONX vinch_p_Page_69.pro
033c372b026d186bc8f53f8985fde388
fbc499758f081d21f8c5276159b4558ec30e9a36
24432 F20110109_AACOXS vinch_p_Page_17thm.jpg
239243a94bbf5cb7a124d67b81e37b2f
d3c680aee33ded656224c32f81757345a939be45
36316 F20110109_AACPEQ vinch_p_Page_40.pro
121230cf792ec7037150ae375702f222
047f09181a22242d8dfba3c4949bbf4bcf55e5fc
43382 F20110109_AACONY vinch_p_Page_76.QC.jpg
2622ec5a1e51da7d89ebf434ed61b97a
c364a0818134c7c2209e797a2aa98ebc72b6528f
909717 F20110109_AACOXT vinch_p_Page_21.jp2
b8bc9c3b1ef04d49e49a992872c71609
9145781ac9d4338b335eb2f6d0c3f76c1eba7d3f
147243 F20110109_AACOSV vinch_p_Page_31.jpg
f98d394072aa34ae816cbc65b5ce1086
775a5af0a05604c6330a65fd1e0bc2f2c8707f6c
48489 F20110109_AACPER vinch_p_Page_41.pro
a83e00487985508d1df9639a6a921cab
5b4894a2e752906fe58a6591670c1d699f36d6bd
F20110109_AACONZ vinch_p_Page_08.tif
8b98f66f5cea5fafdc8fd155b12f1c87
46d8de89a606978fd29eab5efb72faf327a0b1f3
41678 F20110109_AACOXU vinch_p_Page_51.QC.jpg
7878b83f6eb5739eb07362ec6ce560db
d53d050789830ee684cc11a80cc4059ab7124b76
1246 F20110109_AACOSW vinch_p_Page_21.txt
785d34d5bb2df751aedf547dd9417e6d
da97937e65c01f98326d3c8d04d3f303f9fb925e
19466 F20110109_AACPES vinch_p_Page_45.pro
11e24a273d17fa9c12fedcceaaa414b1
420ed62279971a16f268e3b78eb278ec6fdc1d57
8261 F20110109_AACOXV vinch_p_Page_05thm.jpg
ce2c9f8f42a4b8012f74b3a2c86f96b1
e0e38cf08dd8ef3ec0c05ba876bc06bffad54363
151998 F20110109_AACOSX vinch_p_Page_55.jpg
1128d6c090acca70b38c66f61f44d91d
6061bdc7f76c6339abe266c043e5a14f808b67c3
22332 F20110109_AACPET vinch_p_Page_52.pro
46c6205ac2c52d2f851f600d9373ea8f
882a52a5c5e656e57ae37fc32aca929614447c9d
623530 F20110109_AACOXW vinch_p_Page_20.jp2
35ac7d8fcea1f8b0708cb06afd17f8b2
34a9c8a42539a065b1e21449967dc3069ab801cd
58477 F20110109_AACOQA vinch_p_Page_52.QC.jpg
95094353b177eb3d7970be7d4a421914
f0131605a422b2dcc9bee737af3d97de5048ca9c
1916 F20110109_AACOSY vinch_p_Page_15.txt
7d406b6c4e6400d30fc19e2fb37fdd09
f4955d411139ff16db3552f302bb99774f6a6d55
39891 F20110109_AACPEU vinch_p_Page_54.pro
1a308f25e88c414c2fb676e502c27cf1
ddb275f4bf793a00ccfc91b24b718d35bf116a36
41667 F20110109_AACOXX vinch_p_Page_28thm.jpg
cf513185aee9a491c3a5afcf03e503ea
42ab28e66486c3cc8da89fdccf1106f8bf335fd5
184492 F20110109_AACOQB vinch_p_Page_57.jpg
c7475c9585ff00425696a9b3372dbad4
7244235d33dcc235c940fec0c784bfa55d574a60
95019 F20110109_AACOSZ vinch_p_Page_43.jp2
8377f92ebaea4fc3916f4c061ab0b486
c804750ccda2b4900006662a4d7fe3b7a901c5da
24889 F20110109_AACPEV vinch_p_Page_55.pro
9e83969950ee4bca8ce5ea33dc2fd08e
8f337a13e105b98ddca07c0688b541ec28e65a55
87246 F20110109_AACOXY vinch_p_Page_54.jp2
4906876a94b249d5c674b2ab342bec14
80465824d52536769b35be65fa8f38896c24ae54
1451 F20110109_AACOQC vinch_p_Page_22.txt
77bd862ad6a81961e20451ff8aaa83fb
33ffa28c698bae99513bcecd19fcef1ef9508baf
45986 F20110109_AACPEW vinch_p_Page_58.pro
90cc07c7dc658ca6c324f878ed1fa12a
bfe5ba4b73a7cdc0cf5c82f5bf97abb357f62f2d
225226 F20110109_AACOVA vinch_p_Page_13.jpg
0ff932436ed2bfbd84947e694c24e5e6
7ad6eb9dc3f2f6862af0ea596b8134b4df40f1d0
4189 F20110109_AACOXZ vinch_p_Page_03.pro
7096a3e3e8472f473808b7f64378efe1
8238feb8b1b018522d4963b56389bcc1f4d0bb4b
206077 F20110109_AACOQD vinch_p_Page_18.jpg
c10213a38bd955a0ad939f66461a7fc1
b3a1aa91b9ad92b3eb1ee4f91d373f3c8c615a51
14292 F20110109_AACPEX vinch_p_Page_65.pro
bb7b2fb6a462a5830bcfa58434de47f2
500e01101a34afc63bd6f653ccccbeaa4b66122d
6579 F20110109_AACOVB vinch_p_Page_01thm.jpg
0546e98105d442c250fd853a3c6b6750
6787ab2d3cf94b7d3bb5627dbc034b54ab0ca318
62645 F20110109_AACOQE vinch_p_Page_29.QC.jpg
d91050798179e0cee5d98c666ee2c76d
f07b4c24d3102925dabb68c6b628cf7a657a7dc5
41781 F20110109_AACPEY vinch_p_Page_66.pro
fc8c11bd909992d0ed4149202f322e21
761ea503a349fb06600feca5a25d44a85d68b1a9
108533 F20110109_AACPCA vinch_p_Page_16.jp2
b99d73192b9708aa012a0d06a3dd6b9f
b73ba7f8fe20858dc7be0186c0c22ed04d1975fc
49255 F20110109_AACOVC vinch_p_Page_01.jpg
7cb4d79592a6fff98ada671d802f7d5d
25385a8be46b8a2b0e1d37e7a2701115ee84f199
39075 F20110109_AACOQF vinch_p_Page_61.pro
6ea73f341662fa030881f2e11a1c8cea
4f977c5877898dec6c98a85f106d796fc93e7ee7
51221 F20110109_AACPEZ vinch_p_Page_68.pro
81a6f428ceec771385e2a56a2f26ee2e
bd46d50cee4dfa0fd375b576df82021a4e2b7b0d
960274 F20110109_AACPCB vinch_p_Page_18.jp2
006d1be9508e1e80401fa7e935335858
9a1c4b204a4701329f4212d775b65e733d6d2a56
30506 F20110109_AACOVD vinch_p_Page_79.pro
d9de3b5a7f68e2c7ae7215be454b1e4f
73a720419636999739afd6def32e64356ec6f548
1943 F20110109_AACOQG vinch_p_Page_33.txt
98088ef496bef25982849cc2e9343d38
58142252a3e670d40c17967d0e4b1cd0a79d637d
82276 F20110109_AACPCC vinch_p_Page_22.jp2
1fe777186be1ff53df52385a05bf147e
e1cb6e8b421872228170fee499dcade883aeb067
39811 F20110109_AACOVE vinch_p_Page_77.pro
47eff26f5e988b46b4558b1f1fdb75a5
39a137ff8e9532bd369a98667bf742c54f3c132b
25855 F20110109_AACOQH vinch_p_Page_16thm.jpg
c1b740c9734001aa09e6dd373f69bdc8
bff88a54892ab916a447c54d82a5696ad2daf5a8
22457 F20110109_AACPHA vinch_p_Page_14thm.jpg
cb7dd1b84819e46cd8f5b5646f120740
1919331c14bada8b7a576f8fd971708c0db94121
1020759 F20110109_AACPCD vinch_p_Page_23.jp2
c63518803feca9467dc66dfd67949070
705c1587dad293bfc839dbc480f6b80631397e39
9402 F20110109_AACOVF vinch_p_Page_71thm.jpg
f5a8d4192d03258d63b8566da99a2013
0d06d241f6f551fb643217a17e7f873008d61dc7
1641 F20110109_AACOQI vinch_p_Page_10.txt
e3afed3193085bc831b9829fc4d5d159
ae619de2acf944585ae36dfe40bbe04aea6c7884
94241 F20110109_AACPHB vinch_p_Page_18.QC.jpg
30abf1551055dce5dd5323ad68fb302e
277d35381cde15e06d246c7b1f6b98a9d338eeed
15659 F20110109_AACOVG vinch_p_Page_20.pro
2ea4003ecb6d456a817ff7bf4e9b806e
a0fa340ae9744d0c4c0f4e1d0814dcae844bcf7b
184864 F20110109_AACOQJ vinch_p_Page_36.jpg
f56f72d92c4569b40e602caf5ab77b7f
853d290a402c8124b08ddc2dbc3015857ea45c65
19427 F20110109_AACPHC vinch_p_Page_19thm.jpg
02e9902c5d75c4a838b67a4ae63b3e4e
1dfd8e8224c8454703ffaf5b5e8ae015a82abfca
770292 F20110109_AACPCE vinch_p_Page_25.jp2
e9e03aeea1e6a6e5099230d6d5320b22
1f4850b13cd3c9511216382fefd6c6c227ffdb8f
170039 F20110109_AACOVH vinch_p_Page_11.jpg
85dcaef006e2f9eb8a998b66d8bd9c8d
8fa77d7620e38d3a273e6aba1a59d0d61f47a0ca
77952 F20110109_AACOQK vinch_p_Page_21.QC.jpg
afddf084660eaf3501f2ea7bcb45fab5
c83972daf457c0d7f81c1e5eaacc460406a9b894
43335 F20110109_AACPHD vinch_p_Page_21thm.jpg
efcad3db9b465fc73d05733d005e535d
d5065bfabc1aebc16d62b59c395deac3b0116f2b
93430 F20110109_AACPCF vinch_p_Page_32.jp2
534e32936426c8173ec8f095e7bed029
cbd20bb668a00c2699881d7e19cc56252f221645
121462 F20110109_AACOVI vinch_p_Page_20.jpg
423d465b6432808a1a2d22dc31f6501e
97ebfb367dd12656e1c4ba637ab76ce5ba82f063
108029 F20110109_AACOQL vinch_p_Page_51.jpg
b8e8bef2e69a0799fc27de641c0f363a
694146f98529f1c718e3070c1a4e006ab16ecd40
60666 F20110109_AACPHE vinch_p_Page_22.QC.jpg
7982b477eaf167db2e9ead45cd874f41
4bcbc616ed13a37b7514cd4553e0e506a7eeda3e
78183 F20110109_AACPCG vinch_p_Page_40.jp2
e570d73eeff8e80b7e8e21b032ceaa20
93eb7aaa457fd4488f49d386593184e6b245b98c
57930 F20110109_AACOVJ vinch_p_Page_73.jp2
0a63043f9170da2666c2d297d31bd71e
5723f0c3a6be8481329293dd5214f9a063ee0041
28942 F20110109_AACOQM vinch_p_Page_56.pro
4a5c4f26d58c08bf6ae0949b9c02fa21
1b4775742c6246936880a4ffd62ba785cbaf0483
75200 F20110109_AACPHF vinch_p_Page_25.QC.jpg
80330b0ecb996738e1ae53e6edc44f0c
45e0b04099dbe0eaed785e0e32bc446a11995b62
70240 F20110109_AACPCH vinch_p_Page_44.jp2
7966cb1bb830a8f44fb07ac6fa154aa1
9436fded0c9341712f5a822a8e36e909b124efe5
1969 F20110109_AACOVK vinch_p_Page_42.txt
6a3d803e4e4aee3f0d15a57a504be92f
8f141280524bfbcf9ec801988d005fec41c76e15
31846 F20110109_AACOQN vinch_p_Page_26.pro
5e6f9ea7d6a690355a3476abc9a7c991
9c60ce99fd0c39b93c304b48e44bd4c25ee8b2ac
45328 F20110109_AACPHG vinch_p_Page_26thm.jpg
b11395cde91d6cc86360e0bb6eb2f519
4950366a6a83948fd67395862a97d6c77bef61f1
83135 F20110109_AACPCI vinch_p_Page_47.jp2
a28f3896620b30dc764bd86e0e30000c
90ffe48b78c82ae516c652d95e23b38e120050ad
8423998 F20110109_AACOQO vinch_p_Page_48.tif
6ce4cb1a90c6183ab1de645516820571
ef76d62408d8b02ef6acf66b113f6116f4d2a27e
70802 F20110109_AACOVL vinch_p_Page_82.jpg
8d3dcee3c012d9ee53ae4e92b7693da6
ee131c830cf20b7a0c78352d11d4fd4734f63053
53031 F20110109_AACPHH vinch_p_Page_27.QC.jpg
a98490c01c195950642cb89fb5d887be
de5dc20fbc0901362414a70f12e927dd9a8f00df
99863 F20110109_AACPCJ vinch_p_Page_50.jp2
b4953214c4d304a3af329e2d11fad101
0e182e191fd436f862e99d48e14d1843d1bff4d6
20334 F20110109_AACOQP vinch_p_Page_54thm.jpg
e150c5b0b38d8b4d3d7c735be4ec7e26
b0152af1473ba52271d586a8f686e63e40355f27
21496 F20110109_AACOVM vinch_p_Page_32thm.jpg
8977ecb68c9d57eb8d2c98a1e263e92b
eb08b89cbc9fdd2467b9198edf4a4c267c80d3c3
17780 F20110109_AACPHI vinch_p_Page_27thm.jpg
142375ce2f72c169ae0bb94f56ee0be4
d5f55c98b5c817e20d8413cd2ced1f37bd770e72
58367 F20110109_AACPCK vinch_p_Page_51.jp2
fa2278ae52af0c36d6a1a1b850a8ada6
ecdfb527f9f5e0c7e1b338d25f599d07303dbccb
23028 F20110109_AACOQQ vinch_p_Page_84.pro
8a5bf619e95ba7d243e818541be0c235
90b13cb1b6c8cbcb827f445bd95226c7f2ddcff2
29419 F20110109_AACOVN vinch_p_Page_53.pro
b39ee9c06b9762113cbbf09e169cb3a3
7cd57fd5980d92ddcd2d239e2f5ebedb3bcfb261
1051948 F20110109_AACPCL vinch_p_Page_56.jp2
216a2fe3ad825b84ae914e97c7437522
8f396aadc8bec18a7e9b5ee68bb9dd9898160bfc
F20110109_AACOQR vinch_p_Page_45.tif
2b26f9f9d472c576a699df1d0bce78ce
5d1f3f4dd6ee203465e27d99958405175e5965b1
37802 F20110109_AACOVO vinch_p_Page_20thm.jpg
caefd87ce159658e763e57cd7642aec9
4aa4c6e2ca3de0ea29f8393ceee8e1df34034a14
20044 F20110109_AACPHJ vinch_p_Page_29thm.jpg
ce8281243fc28a1e27bbfe867f358619
a3896ee5519048fa76a45c26cb4a237d1551e5d0
832587 F20110109_AACPCM vinch_p_Page_62.jp2
7f731e71956b27ccfead98b4795d3fa3
36b1ed8317abf5d6dbc6140c4b2d94901582e482
46297 F20110109_AACOQS vinch_p_Page_53.QC.jpg
410d1ec602f8109de9f1a8f9ad1dbc0c
84eba918e37f69975e38c9af4c87e1804c50a238
49593 F20110109_AACOVP vinch_p_Page_63.pro
ed0d6dd07c886670f254cdf1dc819533
67bfb31e370fc8bcff26bc08baaa8f4d405f0453
74045 F20110109_AACPHK vinch_p_Page_30.QC.jpg
14d7828796ce059b08a7d98a682dc834
c07961e1f0597cf8f12176ecf60b82060ad2919d
106921 F20110109_AACPCN vinch_p_Page_63.jp2
d2db3eaefe8ce8db71980eda1337f51a
b1814ee1614359e3b3b9a490b66d37e1cf016057
59786 F20110109_AACOVQ vinch_p_Page_47.QC.jpg
0b9b32240d6caaf609871d031c9e7891
d2ebca5fa663142d83bf5ecd97e6749ebb18fcfe
12931 F20110109_AACPHL vinch_p_Page_34.QC.jpg
ce907f1efa1abdb4851e5f448f42e373
5bdaa943714f9c6a7eac5a1265f8f5dd9c5c5324
1010646 F20110109_AACPCO vinch_p_Page_64.jp2
0f5716b9df4b0b4e0d45fe6748b0dfca
eca98270d55bd24e1f6e44e98b3cf1baceaa5a6b
116132 F20110109_AACOQT vinch_p_Page_76.jpg
56716444c92a11f5cb3e146f110887a0
e52fdd0a7bb14f3df3b4b7c5946c68a8c31d4cee
50417 F20110109_AACOVR vinch_p_Page_70.pro
f129f8c79949c0ea19de6614c9a66777
beb4358eb45cb124a0a44a537b78c737f62905a2
5144 F20110109_AACPHM vinch_p_Page_34thm.jpg
71764e54af09bb4f8ecacf61081d8879
247aa7ccbe65c6ab139fa58eba4901ae60c14681
110524 F20110109_AACPCP vinch_p_Page_69.jp2
f90952e0d719cd55598faeafb65c8ba8
c7ae1f9e8e19f698765ab81fed0badade4c317a0
17766 F20110109_AACOQU vinch_p_Page_78.pro
5231fcffe71a356452dc5fb5fe470300
f833efc4144d6fd70dddf50490389304c0b29638
1327 F20110109_AACOVS vinch_p_Page_48.txt
3e2efb1abce7222ef77aefccb3b1f580
8897da9856f75c910de971b2640165078a0385ca
19300 F20110109_AACPHN vinch_p_Page_35thm.jpg
8d02c68424fd6dc3d587fa6b01569ca3
d63942cd0954a20a3505f6880113009f397bdaaf
36898 F20110109_AACPCQ vinch_p_Page_71.jp2
ea86fd1c9e6e3f5052725d1b12da4832
8d597fa8f804758e3d349ba964ece977875577e5
1051916 F20110109_AACOQV vinch_p_Page_07.jp2
2ea10fc9f4bcfd03af8fc44b02588788
f166e194f58f608f3fb7c67489e04c74055f42b9
22651 F20110109_AACOVT vinch_p_Page_04thm.jpg
957b406b8c4d424eb89df5a0ceff8ba5
cc0ed35192c54e7a3db4170e4102625530e70d7f
74260 F20110109_AACPHO vinch_p_Page_37.QC.jpg
9695031a42d3cb48ea4d6801cb5cf6ea
5b0eff16e5146c4de59cfdbdd3fd20b7cef7c4f8
64987 F20110109_AACPCR vinch_p_Page_72.jp2
9526a8265934556a43e41e90cd47aafe
0edff76d396acfe4437bd3ad274180d6503f79c3
1277 F20110109_AACOQW vinch_p_Page_02.pro
e4ae84748aecc7f4fea165c2b7afe2a9
ba86b87250b5efe7bcca81d6d9eda53c3e26eecc
47317 F20110109_AACOLZ vinch_p_Page_59thm.jpg
2e0126b0833d983bf1a53fdd396800b4
d0b743bdce933c7c32b10a8749460912d1535f50
1051974 F20110109_AACOVU vinch_p_Page_10.jp2
bdbe68b00c9370953c0f7a19513a5f95
27541f60a4bcc2e59a9bd050e16c766f4bd049f4
79187 F20110109_AACPHP vinch_p_Page_41.QC.jpg
92ee25fc01925b1bc054bc5954c862af
b9503851a583598b9ce57271d07a82ed6739eb84
44286 F20110109_AACPCS vinch_p_Page_78.jp2
6f1a0a1d9e256a506b9e632b00688147
98170c80e489d85a162a21ce1ac400502e956f9d
40171 F20110109_AACOQX vinch_p_Page_39.pro
a04d8a1b92bfdf72de5eca26f47f14f3
9e6bd58cc9e9749f67ce35e23e17cdc690396b3e
12764 F20110109_AACOVV vinch_p_Page_46thm.jpg
794896ba6692d79ff883efa37aef2feb
911139ff1dcc2a0d6740d86e72311482af9ee2da
23727 F20110109_AACPHQ vinch_p_Page_41thm.jpg
7b4dc09c5383834f4a3cec90bf7e2aa5
09482e59fcbcec4be1a5cbf167c123cbbbedbe62
945335 F20110109_AACPCT vinch_p_Page_79.jp2
847d417283c3772c70770834d2c807b8
b735adbfe9fc5e06edd7c17221b52c30876d95f2
80839 F20110109_AACOQY vinch_p_Page_69.QC.jpg
5f684317e3e7b4771f3f7cdfa84e58f3
6170a6bb6bcb98d5889a5d15c3fd98cad8609db9
209192 F20110109_AACOVW vinch_p_Page_64.jpg
0ea5d635c9b63921f0024d4e9dd11cd8
89dee26b8c61f2c6ac667cc77475917d1379cad3
2380 F20110109_AACOOA vinch_p_Page_09.txt
3f6125f32ad975141a3245cf6f011010
13398e412bf38be1ed2a4aa85b6b38d03915c011
67251 F20110109_AACPHR vinch_p_Page_43.QC.jpg
7c62f37b1f3f191a8604d60da9cb31c8
dae6c937a53f4a7e7b82451d4149223fad954e89
1051975 F20110109_AACPCU vinch_p_Page_80.jp2
3151e6fdb03dfe9c3f43183e940ad4e6
8078c1d53ff99b6cb3e5ae4fb3eb341f5fd7ee23
64979 F20110109_AACOQZ vinch_p_Page_65.QC.jpg
4758e3f07d2a617ced1c6279a2c86a73
734e65d4da6d1d4471c3cb71dff4d5c04f34f545
110798 F20110109_AACOVX vinch_p_Page_17.jp2
4b2648fa008094905292701cf6a75c2f
086627638873170ae5a54c50e7c4a1835147e458
F20110109_AACOOB vinch_p_Page_49.tif
24b4b3c2cf93ab6f2fbedd868e889ae3
605e085ac1a1037806087a6f429d586460b687c2
21566 F20110109_AACPHS vinch_p_Page_43thm.jpg
4c8056bc072b24dff9e17d91cab56f54
93f0ea3e21b45640e1067807e1804270c89a5a89
471535 F20110109_AACPCV vinch_p_Page_81.jp2
0fe341ee4c71d6ece01a1c342e60f2b5
8316d5db8ff452b2b5a3887b184e44d151a4e3de
F20110109_AACOOC vinch_p_Page_67.tif
34a8da61e87deaf13704517329618b9c
c6087a4f00e939da7cdad5e51ade4c7730247fe4
19877 F20110109_AACPHT vinch_p_Page_47thm.jpg
cdc69571e7062c65748d8ea0b968ac51
3696d14bc66a8053003f6b8755f6490d62d66534
35298 F20110109_AACPCW vinch_p_Page_82.jp2
822e27b1f154ad049b1e02e30e911dbf
c289e24b2ee1681e5773aa92cb657220b1226f7d
F20110109_AACOTA vinch_p_Page_05.tif
80733d44233e72e455e69252ee6149aa
2a7f9d951fccfa7d39d50c5aa46a2e1840727242
36928 F20110109_AACOVY vinch_p_Page_12.pro
4397331409a064e94a4702ee1c4b0386
f89fd836b3fa9951912dead423d29a16aaae284d
201804 F20110109_AACOOD vinch_p_Page_41.jpg
395a06d8dd825295aa90c8fe3ea309b3
b381a5fbc879266d215fca63c3f97f325892b3b7
72697 F20110109_AACPHU vinch_p_Page_50.QC.jpg
b52fbd6ce5bc03f90a0d4f4fb600ab40
c4b1ee7edff3b481ccd5b3e7f4e3a6c72fadda09
F20110109_AACPCX vinch_p_Page_12.tif
0f9c1f93232bae17f342365e77adf7bb
81ea16a770d9fa2f9094b3a0f50aaa4514bb4ad5
107531 F20110109_AACOTB vinch_p_Page_70.jp2
211dff6c460d1bafe9c1929b47c67773
5db87a2573e7ee95e46adc3b8b3e45ac5055f7e9
104871 F20110109_AACOVZ vinch_p_Page_60.jp2
7d50e49de324b19e75f154bdee15d27e
338ea08af404df4027a01eb0de618f737c753ac5
65083 F20110109_AACOOE vinch_p_Page_53.jp2
64fd0d7a5887e3b85ff677161571744e
1af15855802806c6177c7e3d8f9abef26ccb2bed
12952 F20110109_AACPHV vinch_p_Page_51thm.jpg
8310afdaf4df2c9fc34dfa5c5533a7e7
9c5d8357e031f54d01052e7178282da54d408889
F20110109_AACPCY vinch_p_Page_14.tif
8cd2a62d01725564e487845e00b46cd4
bfe89bd82bef2ac746820a85c64cf2f9adc63104
35445 F20110109_AACPAA vinch_p_Page_22.pro
0d8c7c6812dd6213e4bc358fb27fa05d
a4bf063502d8993ba972811e1d76dd30511bf73d
54301 F20110109_AACOTC vinch_p_Page_81.QC.jpg
514bea957dd5528ef895b757d5764c5a
3d83cdae5135b58ddfd9fce9120f8adb3c23b43e
61685 F20110109_AACOOF vinch_p_Page_54.QC.jpg
9b25bf3d0868e7c6a57777566a0ef75d
aefc90c1ff644922828402a9dadb1db7f4156ee1
15391 F20110109_AACPHW vinch_p_Page_53thm.jpg
b492f987c312ccded4995a7c7982f10f
81a6fd52d0eba834f4fb4cc142984923e847c055
F20110109_AACPCZ vinch_p_Page_15.tif
e1e425ebc68a0003fb5f1b8c8316d327
8bf4a13aea01c814abce29e809717a5cbe665052
24424 F20110109_AACOYA vinch_p_Page_37.pro
9ae7f7270b03fbccedfe621744fa0a91
84f36a143e29b3b102ed81dd78c608c3f538611d
1897 F20110109_AACPAB vinch_p_Page_50.txt
00663880320d8564072d890b9b7d2066
9b9acbfed3cee10d05b31cfe0c29fcc5e32dd4db
41084 F20110109_AACOTD vinch_p_Page_65thm.jpg
479472d5283306600188acd12081fb1b
551be985254ccd1c4f42c30eeaa88afb304d18b3
27787 F20110109_AACOOG vinch_p_Page_72.pro
e98621a5f2e31c6a1dda3540da6dee35
e658b39012fb78f72e328bce54c85722fddb8496
83512 F20110109_AACPHX vinch_p_Page_58.QC.jpg
f8e148717096f4b336106725e866aa0f
b1c97a685d7edc187d6e3830367797539188258f
78461 F20110109_AACOYB vinch_p_Page_15.QC.jpg
fa062929c6deb4006f4244d4a5f0b442
0b922b1092f2fbbdf1fb2ca1e1e1907bb204f5fe
101923 F20110109_AACOTE vinch_p_Page_14.jp2
24700bbc92771085d61fae9dfba4bc0e
10648c520c1c59837f64ab240db9b8b81afcdce1
208044 F20110109_AACOOH vinch_p_Page_70.jpg
1511a90c37eb1dd25c2edc053026e454
cf53b7b300269f15079bdd93c4def1c90e60da04
97416 F20110109_AACPHY vinch_p_Page_59.QC.jpg
9d159670b6a37c7660f6f03d7f8e664d
37d277e44010ae5b2ac2078b8a5de6ba24385a5d
15582 F20110109_AACPFA vinch_p_Page_71.pro
8003fa6b11c9b62e72c26b6a45a6cb26
0a72e2b67dd5000ef1ab9ad389b984fef32c3095
F20110109_AACOYC vinch_p_Page_32.tif
9882549d5926a5d81ce9c0a49c902c21
0cf4699ee15243dcc814bb2de30b06b05f51d579
F20110109_AACPAC vinch_p_Page_01.tif
ec9a2c8617a24ad0a8f5e5cffbceeb9e
81708151d46347bca681f2fa587ca7915e2c4010
106723 F20110109_AACOTF vinch_p_Page_33.jp2
6361b7686c7d713b28a0b51ea95c56f3
90353597e98b4c37387a4b9874e5a7d49e9395d2
1659 F20110109_AACOOI vinch_p_Page_47.txt
7030cf3d2eae03c9b2ee5b084871a07c
1a0feaa2c0878850d7ee86a4b86f7245a5a2db49
75598 F20110109_AACPHZ vinch_p_Page_60.QC.jpg
bd6b855dcde272e6a6da3dfd805c5c77
a2f7aa4bcaaf4a95f437b7110d8afe463b6a1a26
17305 F20110109_AACPFB vinch_p_Page_74.pro
633199879387fa08bdd5283e9f84e9dc
c98ac9f1c7b73428c7a2820f8197995c118fefdf
166854 F20110109_AACOYD vinch_p_Page_54.jpg
1d034ee6d11ffae2f2a460a170717e1e
74fa0c70748db0633a82f59f0c372f46bc53d22b
22375 F20110109_AACPAD vinch_p_Page_57thm.jpg
d4f944ba3ff7bc432211cbd6e83a0979
ae274d2b3a8bbb91b96a77c85929e93d8983ff5b
F20110109_AACOTG vinch_p_Page_75.tif
983d58e365743f7fc226321993f34c65
1a003f6002c89a6da196446deb8ef432bee22152
F20110109_AACOOJ vinch_p_Page_34.tif
d7bed466c7baeb329c549499cd33dbaa
13358bb1b0c2678d8f2640c158d3e44628f43ce4
53176 F20110109_AACPFC vinch_p_Page_80.pro
6fb955af0a6fcb886d58dbb8dfe68889
5fab84c3d6d62ab1b634979a96564d64f6e15556
41961 F20110109_AACOYE vinch_p_Page_55thm.jpg
474f28b127ebf7be79947c510350eeec
17b822b34ee233fc258f212fc2d37cea3a83f175
28600 F20110109_AACPAE vinch_p_Page_73.pro
b9dbd3fe629f251dafec5cc848aef313
bfae9e28ddc1524cd407dc249765464cc4d7ccef
19463 F20110109_AACOTH vinch_p_Page_11thm.jpg
f9c8745c69badea20c7db497291dce02
34576b101d8f6413c6916fc8a8a5fe58a8c4335d
45740 F20110109_AACOOK vinch_p_Page_06thm.jpg
8c8efbcf83f40409444e20ede413b3b3
50d7d3612273af0f710c368c810dfdd225900379
16735 F20110109_AACPFD vinch_p_Page_81.pro
eb5a4df8c5766fd370f86414c8a3c3ef
3d36bed134458a8031f0ef691593066f55a7a4bf
37457 F20110109_AACOYF vinch_p_Page_47.pro
e6e4ee5402b2e6eae09d8edfc01c3620
29b987da0380dceeaac342dabab964eeb3a54797
7607 F20110109_AACPAF vinch_p_Page_01.pro
be68cf58b2a6cafa66d80a908afff148
8a99f60c22a76eee74e7c649ee0fa3ab797f5852
234941 F20110109_AACOTI vinch_p_Page_83.jpg
f131ab47d4b21197cf18c1f3bcb482c5
35c5576f88e3c4a7ebeb4a692df6b0d2c755e7f0
159962 F20110109_AACOOL vinch_p_Page_40.jpg
7d03d77c740a3ba968e633461f76f6a2
2ea091747de21f067564469fa49b65a9048a7bf5
76474 F20110109_AACPFE vinch_p_Page_83.pro
9d252066896f4cbcc9cbdfd3b46bc107
d75b0603a43f15dc3833fe9f2bc76c3319b01d75
1519 F20110109_AACOYG vinch_p_Page_29.txt
a44c2fd6bdf1fda30dd24649aad17dab
fa7374e59d86ba6cd34f29f87d169b57c577b178
161495 F20110109_AACPAG vinch_p_Page_22.jpg
86f4747fd02c7a1aeaa05fe192537932
5cdd34e997876086c5b8b1e9ade7da9b84a62143
26117 F20110109_AACOTJ vinch_p_Page_48thm.jpg
eadf35a254a30c513938b2ca583b9437
74e2c1a4eee852f47da13c8c3f73dc6494f627b5
21788 F20110109_AACOOM vinch_p_Page_39thm.jpg
54a14a721170b32112025f69b5153283
66196f1c486047d252625c9d5ecc9e20ff5cdeef
420 F20110109_AACPFF vinch_p_Page_01.txt
9da9e24dadb5f233fa2b03218471039e
f9563c7cd9b7bc44c689c2e1eef4668ac3e8c872
89537 F20110109_AACPAH vinch_p_Page_06.QC.jpg
7690cc1dcfea1caf22d658b162a2e3dd
c145605a45ff365bd723f9af1fbb18e603042236
178825 F20110109_AACOTK vinch_p_Page_66.jpg
4707963c00dd2b85905246697af649e0
5dcbac69688b3f0901a428fa87d5d1bc66e4df8a
72873 F20110109_AACOON vinch_p_Page_04.QC.jpg
5aefabd32afb32f177c27d3d3b6dca51
9ad6be396cde212c820a88f53041f8f69cae017b
24937 F20110109_AACOYH vinch_p_Page_63thm.jpg
6c69d552851c4f6dfce491088b3f750e
f376e6a6f67080cf626e3177612052626fc2efc7
1835 F20110109_AACPFG vinch_p_Page_04.txt
e1f7b17a10fbc08afddd77dd0377bc64
ca3ba058706f6f1e41593ef2c256f48d265d5d06
F20110109_AACPAI vinch_p_Page_68.tif
1e81c20c15add9cf44e8411cf6f408ff
6efba097829a388e54108ce07db1853cbc7e302a
25167 F20110109_AACOTL vinch_p_Page_49thm.jpg
45c004656af40a17e3c5becf4d4ad069
69adf2328bc447fa7b136a5b6ac523d3a11a853a
34893 F20110109_AACOOO vinch_p_Page_24.pro
2d128fbd89e3f91e44f7d1e4772f41be
25a32833ebf602d75028ef292fb4cb90104f431d
24287 F20110109_AACOYI vinch_p_Page_33thm.jpg
2ea06ad36133cd88ce8be7945e822519
dd0a6f5c8ade2aa4078bdc9ebe18c03dfc2d029c
115197 F20110109_AACPAJ vinch_p_Page_13.jp2
087e04e801ad9e1ed6ae25325a9a71c2
bf1fa05dc32d5aede7caca37be6d87f66acbbad2
F20110109_AACOTM vinch_p_Page_06.tif
6a6c20325f66081ef465d258aa357f40
b9b356fe90505bf926237775bbb2301159ea04ae
1700 F20110109_AACOOP vinch_p_Page_11.txt
1368857eccc8d6f8f8c354fc2bd41218
23901fe7e724231e623cf26f5af9b33a6c7bdca9
102055 F20110109_AACOYJ vinch_p_Page_46.jpg
d00001be59f9590f80235912572e19f9
10dd4d02cfe81ed868d2b235ac35bad9b5accf88
552 F20110109_AACPFH vinch_p_Page_05.txt
1e6121b39cfcca8835509381ff13c9aa
e53bb39c3bb47917130c465a4a4456fa0d327028
27821 F20110109_AACPAK vinch_p_Page_82.QC.jpg
8fecadbb72bf860b1b33ccdc6866cff0
99931e46a6bb62473ab801f55b7d5f16d85569b2
24773 F20110109_AACOTN vinch_p_Page_70thm.jpg
188cdc21b2b3ed103cf974da1cbf19dd
42f930f3879aead63a43aec1173d76d6a6fc9b7e
193189 F20110109_AACOOQ vinch_p_Page_04.jpg
630d2d54dc347ec07fcb4167ee7a987b
942676c88cb7fc2877c629d2067d748d936eafb3
166634 F20110109_AACOYK vinch_p_Page_29.jpg
0588c4eae59fa756c4142459a1abfa73
1f53c0fb486130fc025334b60bf43d8807a756e8
3684 F20110109_AACPFI vinch_p_Page_07.txt
ceb84afcab0eb2c29f53ff67f25fa68c
87071de33cfcf1171f44a866457a651b43477d79
12718 F20110109_AACPAL vinch_p_Page_78thm.jpg
1cb7d1d3a0c966b5a61f74092a31c474
e99cf1f779e5290d6e743907d6e2c7d62fb6d9fd
29350 F20110109_AACOTO vinch_p_Page_67.pro
2913dd8ff6ae514857db124601bcb58b
00dc0cc89c8ef77c68577a966b4392af11745fe4
953424 F20110109_AACOYL vinch_p_Page_61.jp2
a7fed981d0fdec96ebda9ad10447cc8f
e6bad6cdc87995d6b941dd7fc57874d5054cbdb6
2155 F20110109_AACPFJ vinch_p_Page_13.txt
ad8c9ee5350e3e2f424a1b93a14cf9d3
95453060a93de3d3411f901782ef19e52dac4baa
52876 F20110109_AACPAM vinch_p_Page_49.pro
ce63dad6d38ed5fae4a1d28e84915a32
59879f82ec44165d50858d542a9aea08f4dcfceb
864 F20110109_AACOTP vinch_p_Page_51.txt
24c53c9a03d93ab4a7e33945c1aa8360
93284877168e229d5276475f216d1c9cea8f1143
F20110109_AACOOR vinch_p_Page_69.tif
1bcf412b48330fc817dbebcd87786cc9
682c35f0596fe88ed4f68bc6d9bc59d322335f7f
F20110109_AACOYM vinch_p_Page_77.tif
eed890ad4d440513072c8707c995029e
d7e53ff57515a9274e8693d0e3a020ab79037bc7
1843 F20110109_AACPFK vinch_p_Page_14.txt
1f3d4e5596cf84797c19cadb5a6725de
bd702a738d439da1f4972c4bf2263f302c8e9ea4
735538 F20110109_AACPAN vinch_p_Page_37.jp2
e3c9f0bce0fccc6baac363013b90328c
87c65ac11654c960c6c2928564fcd16a6f4bacd9
60797 F20110109_AACOTQ vinch_p_Page_20.QC.jpg
917f6632d0b70a9e4a428e3246ee6b49
cec352974fb9d6a1285ff7c3ede2b67632ead7a2
14534 F20110109_AACOOS vinch_p_Page_82.pro
f3fcf74ffc7dfd46b002dfa5f960c0c2
32c7dd288e429f22a6711acaf684f1444fe3c2e7
14289 F20110109_AACOYN vinch_p_Page_45thm.jpg
431d85bc706c8111b8b1cef805e709e4
b5ff3769784910c2f57e82c39314e27ce4f3a1ff
1933 F20110109_AACPFL vinch_p_Page_16.txt
4564f89e46e576c6656c40832ae0aef6
23d6e1ab01a44f02027ae2dce45707954b10f835
93279 F20110109_AACOTR vinch_p_Page_23.QC.jpg
92e4f35ac35d4292c7d24ac8678347e7
91a6e4321d4e8fde04bd291988a728298dff19db
607836 F20110109_AACOOT vinch_p_Page_28.jp2
f08ad29b4e7388f4a62de612c71a148f
3ac9847fafc74f13e66f9b81fa947ea9c8f0f132
51485 F20110109_AACOYO vinch_p_Page_46.jp2
a2596a8e8c803510faee755581b5a43f
3d1ec5d317cf6c3aecbc87e166f86f917f386fb7
98364 F20110109_AACPAO vinch_p_Page_04.jp2
25a04d12a59d4ff99da615965e9786f0
ac32d33796ad5d9f168d6a0b684935f6358bf41d
F20110109_AACPFM vinch_p_Page_18.txt
518edfae4b3a68dce712e06026b9553e
e63b0a31712b6495e1139a9a8de0ce3286f74356
15110 F20110109_AACOTS vinch_p_Page_76thm.jpg
daed1346862054276f27728a1e66fef8
27939b4e4ccd8fbaebe85d202d22b7dfff1391e0
213676 F20110109_AACOOU vinch_p_Page_17.jpg
62b00425031c689bbaec5e30f82e8ae9
19d5813da6755e4f80a8e277459e34c35b2531a2
75687 F20110109_AACOYP vinch_p_Page_06.pro
7bc52b6d707871d95239b454c17bfbd6
1be41ba6262f3c37d14c62c772073ca04085827e
75972 F20110109_AACPAP vinch_p_Page_27.jp2
e83017b0a34dc660fda78817b58a5d43
b863d9903db0d12e411704416181ba0d3d84a43e
2071 F20110109_AACPFN vinch_p_Page_19.txt
5728e9954f4cc3bcf39fd722be2dd29f
df573b3addebf723b9c396fd726a32d90d18a423
F20110109_AACOTT vinch_p_Page_21.tif
de4f46417890c82749e2aa6ee3c72baa
e7d068e31059a89df5009fd4908184d2bc193167
F20110109_AACOOV vinch_p_Page_83.tif
30df0cc4ead5442ffc0d64b48d981f95
bf66c3e92fceacba73cb22233047fd4f73c3f8d9
60570 F20110109_AACOYQ vinch_p_Page_12.QC.jpg
6ecd881a66fe048233bfeae5d094bacf
ccc710c6275f87f6a30ddce2b8e10b202b97f670
195073 F20110109_AACPAQ vinch_p_Page_14.jpg
f07d8b7c7b41a54c570135ee321845bb
4fb36d04e00bdde4e92f66692ce703fe022a241b
797 F20110109_AACPFO vinch_p_Page_20.txt
cbfb39095aac59758bdf7dc41a5a8a73
c472712e70e5ce7dfa5e8890ea1a68da5ac954c7
734 F20110109_AACOTU vinch_p_Page_81.txt
c4143fdf0b67a17bb0bc2675041ebb6a
55e8533653e5e0cf20808484e84be45a2fc9cd44
47587 F20110109_AACOOW vinch_p_Page_79thm.jpg
6daec19ff12d2b006248aad1cbdc854d
b6d7c253ed472de0740f9aba6dd189a323dac06b
45829 F20110109_AACOYR vinch_p_Page_04.pro
f30fee9502a46ed2438fbe2d9426e3b7
6e5cb988c84dca05ee714e92127fdb1d8cb6dc3a
126347 F20110109_AACPAR UFE0001146_00001.xml
1ae39c4be6630876c1ba1b0eb4ee6669
cfc0ba81ca7dc904807d86f6e818be2ced604cda
1003 F20110109_AACPFP vinch_p_Page_25.txt
5a8467d3100bde9e457eefaef7bcad5a
0d1eebabef60703ae583f5b26ea6f02f59f000ad
1913 F20110109_AACOTV vinch_p_Page_60.txt
ea6b279b5a7f9d0d7911a2ac20e4a3f9
4a2f016fe0ab13d72b5d357716bfaa755a6d75ed
1798 F20110109_AACOOX vinch_p_Page_61.txt
4c19e446fb845dce357816e9bb07f1c8
fd454d22bb66576f982106fd047d75dc8712213e
17906 F20110109_AACOYS vinch_p_Page_52thm.jpg
0a54b7ce314511fe6dc32e07c06e7c42
a4527335d620922999fd0dc8636bc98ea886c218
1788 F20110109_AACPFQ vinch_p_Page_32.txt
52a83dc480b7f11f3bae7eef12d73328
87eeafc4a23f62e195fd0afe4b6c1cc6303de829
79742 F20110109_AACOMA vinch_p_Page_29.jp2
ddd27ebc4dced6291e078584c14c8f9f
6239cce0b53925babfd1b398ff27667115ea81c0
19614 F20110109_AACOOY vinch_p_Page_51.pro
a9ba6b158f7a545e122f6c11351e4f29
e87c31f60f69022cd2a2f104a59bb96e507d1a9f
1226 F20110109_AACOYT vinch_p_Page_08.txt
86ba270679a268e032b7839710b96a58
19a5358819134ecd3f8a70b1bc332aa64c3965f1
262 F20110109_AACPFR vinch_p_Page_34.txt
c4d18fc9c025985613590c6b737fd881
5dfd6d77060ad128fa3f62499201254e8a1260dc
F20110109_AACOTW vinch_p_Page_54.tif
ac54a0195c4191f28c8605821d3fe66c
b3a639a8eccca55fce844a0ecc844c3dfbb327e9
248835 F20110109_AACOMB vinch_p_Page_80.jpg
fdfe408e5ced09ba2a618742c5b70cd5
8911db1c59cb9c4b987a97843ca8524d7d4ebe3a
746129 F20110109_AACOOZ vinch_p_Page_48.jp2
7cd79499e7d1f917446572bebf0965f8
4688d74378294068c3be1c37a8a69b7176c230c4
159901 F20110109_AACOYU vinch_p_Page_24.jpg
52ef248b7ba6e21a62c34f00d67b5ff1
e4608cff38b93d03576fb6d790c96b548c85ca99
64338 F20110109_AACPAU vinch_p_Page_05.jpg
9ff27678673bcf672b210e17f852ef45
3f95483db0b3cd0b63e26a6fd3e0d988e3d8f8b8
1558 F20110109_AACPFS vinch_p_Page_35.txt
3df5b8d7e20d6f9e0684497b66e0d20f
e41452f62111a127fdfd31ee34f096379db3926e
106690 F20110109_AACOTX vinch_p_Page_42.jp2
b590127fd8562533a11487df21e6928e
553065f4ed97726a4529c993b2abff7128ef83fb
123398 F20110109_AACOMC vinch_p_Page_65.jpg
92c0684e549cc05fe4eefe55276f74ae
622ed5969e86e08600e9d795560ccbcce9703ca6
30198 F20110109_AACOYV vinch_p_Page_44.pro
490733b1d4cb6e7f5873e71f869ccc2f
c022d6b747d56b73fc36f61f69ecc489a0000c9e
243045 F20110109_AACPAV vinch_p_Page_06.jpg
d60c840d6adfda303dfc503ee046f5c2
591dbc8280113481289528f6b8c2c55ee113926f
1565 F20110109_AACPFT vinch_p_Page_44.txt
3a4d205347eabf599c310a5804a0136a
d86f81397093b266a3dd56c2586d4a4c4f3f4272
228871 F20110109_AACOTY vinch_p_Page_59.jpg
91421ae840ca3e8e8abdc48e701b59bb
b376f4cdfdc8670bc69208f20ef9317d91700dd2
881 F20110109_AACOMD vinch_p_Page_65.txt
2623fc55f702be353d87a486d8c5f7bd
f2bdef7d4a42dca0378e378dd747dd3931c09bdf
F20110109_AACOYW vinch_p_Page_73.tif
e6b113cb6b12bb1343748b6b23baadf0
0e17c78ab3eda04621614e88cf442375f66d5b38
305757 F20110109_AACPAW vinch_p_Page_07.jpg
380389fecf61ca883ca3df8ffaae5f67
b10fe2e78d3751d13640574c2229a96e89dd760e
117812 F20110109_AACORA vinch_p_Page_45.jpg
f0c67fc34c5efdbf6b25e4d65be86d5d
8dc9569391707708de85b629be51dbdd3b3f68f9
770 F20110109_AACPFU vinch_p_Page_45.txt
6af7bd03c753a2269012914e7b8d2404
342869df72bbcaab378488a1b377056769d05024
110589 F20110109_AACOTZ vinch_p_Page_49.jp2
c87af06a7697e623499f8948a6c1fc98
5f17361c243e905caae079fa92cb60cba5641bf1
213113 F20110109_AACOME vinch_p_Page_63.jpg
dc0b1ce3603ba6dca2a6955a8480bcbd
7cf015707c3c8eaf035208ac792c792dcf0550a2
82421 F20110109_AACOYX vinch_p_Page_77.jp2
32264146431c9aa2acee4032f5cfeca5
6733af2679abf59443de3b55fdfc7636d0ffd9fb
230417 F20110109_AACPAX vinch_p_Page_09.jpg
9c107c99da167808a8f573e070f3cc5f
280a8743b13ff07601f8e11ed6c8fb9ed5935919
1595 F20110109_AACORB vinch_p_Page_12.txt
d550f48dd971bea86e5085bbc43214fe
a4e5c5e23a1dc9bd5068eeef6c2b1ef09bbaa639
548 F20110109_AACPFV vinch_p_Page_46.txt
be65ffe3ead88f4fa60b7ab4ff760d96
8d92da164c27180f302861ffdf9d18bab4dd340c
46757 F20110109_AACOMF vinch_p_Page_14.pro
eaa7bf6b306abe9917e509aef8da2bd4
95d4d1646541d2908b11a9cca36f9ad0541e99d4
17929 F20110109_AACOYY vinch_p_Page_31thm.jpg
5620bed7afe24ecf5426d16ebb3bbf8b
c7305d2d177ad2d1864901ef1d4600128781546c
179052 F20110109_AACPAY vinch_p_Page_10.jpg
562b93541f1889e051e2d6b20e71427e
ccbada01e02e2d6fba8fe160d771327611e91bc1
21223 F20110109_AACORC vinch_p_Page_38thm.jpg
771ae44752df0fd34a7220d6cd64040b
b38263c9bdd2168837cd79ad4d87d798874d5f2b
2074 F20110109_AACPFW vinch_p_Page_49.txt
fdd1c68f01cb8dfc48fb47e7668f94aa
a48715f7693ba287f916377aa0e9fc4339ac4bf7
20049 F20110109_AACOMG vinch_p_Page_22thm.jpg
6c55579b0a959db0a4263a3d6105749a
c01bffafd488d1331b9c8d6f20f35bfaefcc4766
F20110109_AACOWA vinch_p_Page_25.tif
858bc488f352c2237d4100dcaae7bdd7
6e753d8431952735f7c96b840d4cd58515a977ea
70255 F20110109_AACOYZ vinch_p_Page_71.jpg
99e7f8f6fa3b0612ff830db33980e88a
2d9e875bb8872168ae5d537c1765d01f62f1cd8c
207804 F20110109_AACPAZ vinch_p_Page_16.jpg
36ddb9d544e19b57c185724d7a6e3499
39285c6b49389848eee21c644b618968c14949f9
158433 F20110109_AACORD vinch_p_Page_25.jpg
3400ca62149a35bf6b50634556e1286a
2faac0c05419f59ee6c2e505dd9f2359fd62ee5d
902 F20110109_AACPFX vinch_p_Page_52.txt
ef4058aefd75dc5ee30d9c537c977e00
7d9e892c3e6ac2efc860e18591b62dc66d8a3f53
43432 F20110109_AACOMH vinch_p_Page_73.QC.jpg
aaf65f53ce01c69881399570a66d05c6
303ade621996e8029fcf43df9f9de6587194b6f1
79664 F20110109_AACOWB vinch_p_Page_33.QC.jpg
1cc172984b1a56a75f28ca63076938d3
0e08be16d8c9e146627cb640387a4f176246bfeb
F20110109_AACORE vinch_p_Page_03.tif
ed2e5396278529a5d813a9d41d62a838
d9b6559a03ff3f61bf6c719fe8f745e920423bdf
1672 F20110109_AACPFY vinch_p_Page_54.txt
390338660c86017e21710eda0482a3da
23dd2eceeaa793b7dd1888f52d7ecf73a642d127
F20110109_AACPDA vinch_p_Page_16.tif
088c729d5f2511bf41d1c116f4c3a88a
39da21327f7f9a2fd8560fe8942a1000ebb64902
40577 F20110109_AACOMI vinch_p_Page_74.jp2
3589e276f21e5b0210e66f066cf01bb2
fef12e696fb1d7025477fc612f4add922e3a543c
133642 F20110109_AACOWC vinch_p_Page_08.jpg
8de48f986f4e56e44b749f7ed488cf10
cf08c39843f31a43f806dabb9ff732ef27dd1630
48043 F20110109_AACORF vinch_p_Page_64thm.jpg
dc762c264dfde1772b21289696da19d2
8ebb90a12d5cc6313db9400328df5d9ecaa77dab
1176 F20110109_AACPFZ vinch_p_Page_56.txt
15f714b7dc039e4638ee2316be1157ea
7a5cd672b9d7d699ff6239fe47622327efd767f6
F20110109_AACPDB vinch_p_Page_17.tif
f5e77371d55e52f44e6b92e1be6e80e8
1a5fcb836497b67682a230359deac89e14d713a5
45428 F20110109_AACOMJ vinch_p_Page_57.pro
140d571086a45704c2d27abe335adeac
8be908426c70c2e78a18c6089b80b0933891b226
35376 F20110109_AACOWD vinch_p_Page_18.pro
a3cfdb59778a51f4a99a776fd8df5ce2
0023a35d321334f635524d558ccfcec199a4c0e9
22453 F20110109_AACORG vinch_p_Page_36thm.jpg
3792a99f9b7611af71bb848ce3634a69
6667236ef5f9dad3f1a724704d65f241d5a42541
F20110109_AACPDC vinch_p_Page_26.tif
4080a60b727e08e8b120a62fd61b939e
330136a30e980fcef80e7d95b24d0a55218aa3fb
69471 F20110109_AACOMK vinch_p_Page_36.QC.jpg
edecc2c4ca82a42c1163224f613f9030
ea27a0c525bbd9e4230f320b89448a7fd5abcfc9
104388 F20110109_AACOWE vinch_p_Page_41.jp2
b1ae2c809ded43e2ac2eb64df4971a7f
a3cd7309dea83cbef978dba141671bd1df93f919
F20110109_AACORH vinch_p_Page_55.tif
565b89409f6ec33ddb2e844f89c6a2a4
7b81f1b112149b77ef31108cc033499dd30aef95
24389 F20110109_AACPIA vinch_p_Page_60thm.jpg
4a7d13e90925b4943bbcea65487e73c0
3a86d5975bb7c068a097cf5aeeb6a2aca75a8934
F20110109_AACPDD vinch_p_Page_29.tif
2c3beb31c2103a96685191c1a6c4fe9a
4449a25d37241a20aa66f03fd8eb047d233d9dc7
1371 F20110109_AACOML vinch_p_Page_26.txt
cbea20bb84b3985e99ed0fb8b11fe1b3
64df87625d777fa5ac792ee5a1cd2b11d56f270a
78792 F20110109_AACOWF vinch_p_Page_42.QC.jpg
a0d895df5e79bd46dcae2fd45cf2fc12
552b9b86b8e24cae19568b45cd5e65c98199695b
41418 F20110109_AACORI vinch_p_Page_37thm.jpg
907ab51f37527638e4b6b8152a78e968
b3445b4cc368b4868fcfd978802dff21a09b28b1
92620 F20110109_AACPIB vinch_p_Page_61.QC.jpg
c43f33db5551dd22a7cfe82f00f61b98
17cead43ebac5d1a166489ae282cefa17df6c15a
F20110109_AACPDE vinch_p_Page_37.tif
aa57f5f9c60d3add78d8dce0640176e0
1ed30e23bde25a32196ce018e3b7ec1c973455dd
17458 F20110109_AACOMM vinch_p_Page_44thm.jpg
69694519658e2a3e997f17337fde96f6
156b054278a91f54bbd561f3efaa074e5ede806e
2059 F20110109_AACOWG vinch_p_Page_69.txt
5de5f51c2fd00fc932dad932ec1e3376
a85b59fbea977cb8c14c822f67e1d9a54e4b3a89
876408 F20110109_AACORJ vinch_p_Page_58.jp2
9fd3d4e0a028cabbb2fe49885d17e4d9
d48c58ca160ac442dd7fdd5dd6bbfecc81d968ef
47106 F20110109_AACPIC vinch_p_Page_61thm.jpg
31a1c2916216b1e0ae27f06fbda05143
3485415121d72f138832ea14b8377228b6ebc104
85163 F20110109_AACOMN vinch_p_Page_11.jp2
594635f1dc6ac8dcdaaaf6cd8efbc11d
5d61e384d9a536420edf48a6dfb7fc735cfee360
24180 F20110109_AACOWH vinch_p_Page_50thm.jpg
768b82d41418a242c91521eab04fb027
a44848a0db2169216810c07c17073df40fdb3e21
31093 F20110109_AACORK vinch_p_Page_34.jpg
47bb725c69fe157a9d7ca3d430dec3d2
ef3f711be666e884630a7428eee1d048086cbf22
94327 F20110109_AACPID vinch_p_Page_64.QC.jpg
b17da47a0d364f082ad2a005207bd388
b2cf4a329965d390e9ebb21675d266aa75ccc7e1
F20110109_AACPDF vinch_p_Page_38.tif
b8e828313bc49dc3168daba2781163cd
1171d42d85312c47cad3b207afe1967c5baa9d59
46577 F20110109_AACOMO vinch_p_Page_75.jp2
086a6aed35511112d8d1bf19a029b16c
61ea6a6de1b0e69d866450a45a264bf9fc90387a
19559 F20110109_AACOWI vinch_p_Page_24thm.jpg
7d9da8ca04e03109452f618eedf5aecc
25a3623e60907dd6f27b983ef00cf88e67c3edd6
42983 F20110109_AACORL vinch_p_Page_19.pro
2809791dad8597a0ae5c59753cd28cb8
f7b59513d3d07d407a5d8fab2c2ddd0cf5cc2517
22060 F20110109_AACPIE vinch_p_Page_66thm.jpg
53151804aa57b4f893a73be5adc3eaac
6e949acf1c693156f0117a2c498fd200a8852194
F20110109_AACPDG vinch_p_Page_39.tif
09ad85c70b80f53077a3614f2e7dd65a
eb061bae044c96f71b3a8598e3869a44bd8acbd7
1303 F20110109_AACOWJ vinch_p_Page_23.txt
8f112d81e29140412ed97cf8647b36e7
b82ee02da2e17600faadda2a84a2f5f4070e6a3a
1490 F20110109_AACORM vinch_p_Page_24.txt
1d62a3bcc780288d0c81a86a5a11c29b
2c840d96b313b26af1e154e24601430618c543bc
104887 F20110109_AACPIF vinch_p_Page_67.QC.jpg
e95192c9837956c88a3549cc84eb229c
796ad69dd2f1fa605cbd56afc17252e3978b7c20
F20110109_AACPDH vinch_p_Page_40.tif
49cb751bd281bf7564d549a9dd320dbe
80b2425f90436bba93fbd58172a47452c750d9a3
50031 F20110109_AACOMP vinch_p_Page_42.pro
8a20585a8095586cf9e49d2a88318dea
096e572e949732773a6d0ff0b4d46cfa37c0e9c3
58831 F20110109_AACOWK vinch_p_Page_76.jp2
b21addfd099d94b9cb9cad7005c139a1
006e9160614160c1ea9356fdb74d1a3d941ae6ec
77943 F20110109_AACORN vinch_p_Page_63.QC.jpg
7de7190771122df5ab9ac3fe82607776
c3db3ffcf9a3a7422902be2466e02597806cd745
80276 F20110109_AACPIG vinch_p_Page_68.QC.jpg
ddbf834eed56aba98326103a83fd2313
36307d1ffd19861ce067015f069d736318ee75fd
F20110109_AACPDI vinch_p_Page_41.tif
982e9d1197923f0d1ea0181bfd3035e9
657701c1619cce6718857ea837a3bda1ac447418
624 F20110109_AACOMQ vinch_p_Page_82.txt
d4ec53aa735afc8159b798e99dd802bb
6f1e8f175fa00f49a14b053d63beac342f59a268
F20110109_AACOWL vinch_p_Page_52.tif
7b6a363210def6a06872a713e5f18c37
d29d14be2c72a6875e54995f21e756d0d514aac5
F20110109_AACORO vinch_p_Page_35.tif
fd39b5765aea0939d82e5a7f14fb6b3d
7d6a008a426edd662cff8fc5ab6e0a7b36af7fc0
25269 F20110109_AACPIH vinch_p_Page_68thm.jpg
cfcbfe742b117b668ed1ee9c6c9c7c7e
e0c7dfac594c39c0954e2cc0724084e4fc3cfc0d
F20110109_AACPDJ vinch_p_Page_42.tif
960f2c5ba955b4fe07238ca0429ba3ff
344ba747910b2668718869e6b7efbf1ecae3a90d
91058 F20110109_AACOMR vinch_p_Page_36.jp2
0f3989ce021b0f3458a48c1b47e4d373
2a4f71a766ebf41a5ffb483d781f8af752f3f9a1
F20110109_AACOWM vinch_p_Page_36.tif
4119f4021fb375050c04e8d7eeec049a
930fb99c02414845a46894063c0e226d82fd2af2
163329 F20110109_AACORP vinch_p_Page_35.jpg
e4f963eb9aa88cd41272b839fd352689
2bde92c448174d2d922cd9e3337ee5442ba335c2
25626 F20110109_AACPII vinch_p_Page_69thm.jpg
b4cb7c0a1c0284755dde46c8abf577de
622353c77db11ae0b24cd33d86cf7ddf0adeb922
F20110109_AACPDK vinch_p_Page_43.tif
8d449cdd09f92a64b590c6ee0538ba71
0b1beb8129c772e5a9eea413dee7fa64ebbd9e5a
F20110109_AACOMS vinch_p_Page_19.tif
004cf5131555ce3905f54f4029d0a1cf
f556a81675cdcd501d357b2669813d5f31f5bd71
94978 F20110109_AACOWN vinch_p_Page_56.QC.jpg
2b517bd5d0a8b4fa66921ff6391044c9
9b3a967304c8ce7968a0eadbf2246704e5bd164c
14306 F20110109_AACORQ vinch_p_Page_02.jpg
98fc80b5605e6e2b9f98d4505e017187
18994d81d4f3981a77288dcf99eda18f2b23c3d3
16451 F20110109_AACPIJ vinch_p_Page_73thm.jpg
632966b6b231e38d236aa4b8ff577d2a
3f449154d7a18cd82aab5d2a8b42174b2e301660
F20110109_AACPDL vinch_p_Page_46.tif
72117e789ef21c6dbdf6f29856f92790
d28a41de545868010d59767dc2a1daa26d8dcde4
42331 F20110109_AACOMT vinch_p_Page_25thm.jpg
7cfe71ce7a87b503b1bb76aa900c1ad8
a0585f9e71d3c17b3a282c6026d5fa2f17df03c3
21178 F20110109_AACOWO vinch_p_Page_59.pro
fdbe6ab2d9b6d8a5bda9dcb64d71611a
72841303fb04f7a44c42fdbb04a35126a180a6c6
52689 F20110109_AACORR vinch_p_Page_44.QC.jpg
e43d302d1dc2d0b3ffd21f2d7eadd35b
2cf80fc036e29eca10dd1723158879cc2704702d
F20110109_AACPDM vinch_p_Page_47.tif
b3d6bdddd287f17414542aa277ee3d08
2d8ef3f8516571b37b931be0d15dd6c3be7df0c5
30795 F20110109_AACOMU vinch_p_Page_23.pro
5adb9bbc8d8520545f2a38d09c06df70
1568b086780558a06552b5d076da1f40b5f66a78
47070 F20110109_AACOWP vinch_p_Page_18thm.jpg
7aa8195bebe6be513178a3c997887676
4d1fc1fa67db47a0254b06799f0acdfecc0f12cb
215772 F20110109_AACORS vinch_p_Page_49.jpg
51779b1d9a517d171cb384ca81960ac2
334b4e2f698cdd1e6f0dc1a9575427f6f7339fc9
29926 F20110109_AACPIK vinch_p_Page_74.QC.jpg
9a2691bcdb4b4e4b07a61d2dfb38abff
c570df0a9240f6cd2897ba4ecf6e985f65931d1b
F20110109_AACPDN vinch_p_Page_50.tif
6bcc711eafa6473ae18b89ed2cc1aefa
549a881ac55c417f0bfe9e367c7c9143c0d89b49
F20110109_AACOMV vinch_p_Page_78.tif
523688f5e12bcf1b926738c61594e1e3
9312a1811948ea5cef49a596e9fda7e24c34a65b
F20110109_AACOWQ vinch_p_Page_57.txt
b5ec6ed5460f9ea8890f8a892a828bda
8d3d285b3a58d48b04d9061d923ef7fcc5928d32
1655 F20110109_AACORT vinch_p_Page_39.txt
dd2bfe2394b14c03dd9c2ea1cf15379e
5de49d055d4897fa7f32afd304c7006295c7b65e
12321 F20110109_AACPIL vinch_p_Page_75thm.jpg
1a44395eeb8ebba4019bc6829562c6f8
647180ea6921da18f9f4e51926967bdf16ddd95a
F20110109_AACPDO vinch_p_Page_51.tif
a8bd20a99ad2961a859a7e2996c9a0db
c865243db777e0206a9dd4e72feda8a6c36210e7
65795 F20110109_AACOWR vinch_p_Page_38.QC.jpg
b7600d049e9f7ddef607824971dcbdcb
e45db6f393bb8629809c7595e88c2ba6be8883cf
F20110109_AACOMW vinch_p_Page_04.tif
8054da4f926aef49fa42a096f92aa943
ec6562b4f125d12bf8277e014b92c69f48298273
62409 F20110109_AACPIM vinch_p_Page_77.QC.jpg
6a81ff62f3089751e2fdb7660293dd7b
fcd7970a5160420f1bf045cd5e65d29792a1c294
F20110109_AACPDP vinch_p_Page_53.tif
2fff303ef84dd10f85c410063aa8da08
7cc64212b6f72017ea89ed2d366d4445ab75eb94
825649 F20110109_AACOWS vinch_p_Page_08.jp2
d8990b8d983bc5d2498d779ad7a3a37a
30da3df1d4b9af2256830f532f37f04ebc40b107
61989 F20110109_AACORU vinch_p_Page_24.QC.jpg
e88cb7510c0d4796992768330cb31b63
e183c570e646c5f87b52816467660d4613e7adc3
1296 F20110109_AACOMX vinch_p_Page_27.txt
0c904f35ac8502008aeade1eda993414
91beb2f9f00688f538acf13b1ac805d46e68c089
33209 F20110109_AACPIN vinch_p_Page_78.QC.jpg
4921f1470b73aeef57cebff843817edc
1152bd30859696dd8fcc5a6a27ae91f3d4668cea
F20110109_AACPDQ vinch_p_Page_57.tif
e232ebdceb24b0b182b6ca9e403550c2
76e340b9d798dd58ea72d41f964a11b313475d85
46665 F20110109_AACOWT vinch_p_Page_62thm.jpg
e7082c335ea4c1df94a22ae892146509
c21cd4c425d036111267b5b70e629c2795114db5
25444 F20110109_AACORV vinch_p_Page_03.jpg
45b8adf68e16461d2dc98465225b5ffb
b6e275b58d96008989408db987b325579dd85696
80573 F20110109_AACOMY vinch_p_Page_13.QC.jpg
b552c64f34dea8a24547b2f845bb1c42
c38735fe092fbdeef02e064cb8f62128c7b047b6
99438 F20110109_AACPIO vinch_p_Page_80.QC.jpg
5b0ccad8e645b00908929ad9624330b7
fa00ac76630162c70a12561480e89475060fd09b
F20110109_AACPDR vinch_p_Page_59.tif
f5378abd7e897992df92407d00d48d0d
ecaa86481bf4474b28fb3b571507251dfa2cf616
110876 F20110109_AACOWU vinch_p_Page_68.jp2
e5adcb356adc20118c7c36c8f6ea29ca
d721d2cacc078028a5fa2b6e3b68f0ac3e1244f8
F20110109_AACORW vinch_p_Page_84.tif
1ccbb82b830fe2dd075d79c714faeb94
05f3101fa5bb119de690e3aea191c9157e9db28c
45480 F20110109_AACOMZ vinch_p_Page_58thm.jpg
29443ace63e57bb23fef897debef0cd9
310dcbf32320500bb1c003774b45842b3a32ffc2
48704 F20110109_AACPIP vinch_p_Page_80thm.jpg
0de88110f3e37c74773fa817515864bf
4e02b2bdd27d3da9a6c1346f0741c9ef23558aa6
F20110109_AACPDS vinch_p_Page_60.tif
e64c038959e8e8d16085d44254d8ee3d
0bf5b61145d7b3e0e6187b90a480c43ab7b0d5dd
1204 F20110109_AACOWV vinch_p_Page_84.txt
8bf2745e1939373869f36fd5b2d1ad7a
e98410d8d988aac379958470d438461a70073ab2
66336 F20110109_AACORX vinch_p_Page_66.QC.jpg
effaca30ca4e2a350cabf21b5bf02cea
17f18f2be9f8296ac734c7111332904b02a18822
35003 F20110109_AACPIQ vinch_p_Page_81thm.jpg
29374cd5c677b9493e47ae12ace6a66f
cc03ebf56e9357273b4355deda74672141246ef1
F20110109_AACPDT vinch_p_Page_61.tif
45eacebbb2a2ce13e9b40e0c98151cd3
2c767c79e7789c984fe3f916b48fde7e5f715ada
F20110109_AACOWW vinch_p_Page_18.tif
93f7bcd42959dd2c1e955765eee0586a
a9cbbb8a04c4aafa654222576a9e31ed1fd0f484
8642 F20110109_AACOPA vinch_p_Page_03.QC.jpg
bed7c89a699138422bc82237ceafcda2
3e999e467201fc5f8646326b6083808048a14c06
90136 F20110109_AACORY vinch_p_Page_39.jp2
a31b7aaaf3bd7b295a20d0755945b882
732fdeaa9a7fe8a415f141e22cb073fc99cbb014
90602 F20110109_AACPIR vinch_p_Page_83.QC.jpg
a4af0c933f41ffe3b454638be6739239
e7d76f638f6d6f1cba2d3b49c20b54e2236d90dc
F20110109_AACPDU vinch_p_Page_62.tif
fa089860c79dbbd70b453744716ebdef
9f9d2d003f5361d8de0efad7c26e70e8431e3da9
51163 F20110109_AACOWX vinch_p_Page_17.pro
3673886d18d2d32f93c430e28cdce82e
ab01e0e0ab8dcdcae7741c6da15f8b1bad28838a
24476 F20110109_AACOPB vinch_p_Page_15thm.jpg
c8444d0f1f8836c5efbce3a48489127b
18bf0b35f04ad0774c468849ce2bd35c1795a7a6
18641 F20110109_AACORZ vinch_p_Page_40thm.jpg
ee71a1cbb4e07bf21d2bf84d9738f625
3be79784210d38440175457150daf23238a83516
68565 F20110109_AACPIS vinch_p_Page_84.QC.jpg
34c2c81edf16a35a4f3b8dd252f3963c
fc21b368e00d0a8114c35d2093965ead9adf64e4
F20110109_AACPDV vinch_p_Page_63.tif
905a42c32e95ae253909f6407699f910
7781043f428225ce4b44092778a27788692f7660
98580 F20110109_AACOWY vinch_p_Page_57.jp2
43760c77b4bb0214b806de8905b0afab
08909045de3888c27e6c4b9ef83dc91f97c6cce3
60657 F20110109_AACOPC vinch_p_Page_19.QC.jpg
570b8fe29a6f57f56f053dd0cb862260
91d1855a69244c55773b96f4a868f69775812f56
39882 F20110109_AACPIT vinch_p_Page_84thm.jpg
caa0e8cdd2924fab20ecc96400ee91f1
5886eff22e9bf87bd73befca2174d4cff4a7cdea
F20110109_AACPDW vinch_p_Page_64.tif
9d72f22b1720359cc7d221d2f79b286c
e2f859133258eaaadedc3ba89f8dbee35505e4ca
158927 F20110109_AACOPD vinch_p_Page_12.jpg
ac33f511cc3914a875c3ab376a5fee67
e685ccd17a9ef018529b5ee461aba4b93148cdb2
13880 F20110109_AACOUA vinch_p_Page_05.pro
a6a6cf3061682dff52b0896f1d67b1e4
cbece699247d7360bf0c928a8087eabccf5e91cb
F20110109_AACPDX vinch_p_Page_65.tif
8e26360a550847cb03ab431940f4b36a
2dd3d54133449ef17481cda42d4a92a37f08cb7c
206106 F20110109_AACOWZ vinch_p_Page_42.jpg
57cef873ae9d512cfad824e54d58e235
761236d52f11db2e2188a31f058e2df83d4eb86b
F20110109_AACOPE vinch_p_Page_24.tif
22b84f2606f550c83bf1613e209d0e92
d53ed864d179a708a8a6018d785c2ac671030db2
81219 F20110109_AACOUB vinch_p_Page_49.QC.jpg
d4604401a31dcfd89b21a8a7db864f0a
f1433d6fdd7d0439e81e814f3d3b0f2ba2840c61
F20110109_AACPDY vinch_p_Page_70.tif
ccc709bf4d2bce63012b9a3848718bf4
5de760da1468eab8e9b5a72d11e193036e88b726
105 F20110109_AACOPF vinch_p_Page_02.txt
3efdc49f9bcb69a07c036d4ebfe8b77b
7e4ccaf1ac0a9247c481148bd939e3a885e2a280
157665 F20110109_AACPBA vinch_p_Page_19.jpg
cffa56fb8878c98a0d18434afa81954c
2b95fe919d4bf6c3991c778f286d77890ef34da6
29965 F20110109_AACOUC vinch_p_Page_48.pro
3c50111ac36d84233bb0f23e43cf08ed
95117dc7cc711865caae60657af7335251d12c98
F20110109_AACPDZ vinch_p_Page_72.tif
035b4335c84922258d1ca60fe1ac5da1
55775034225d186dc2a276af8d2a5812d1aeedeb
78817 F20110109_AACOPG vinch_p_Page_70.QC.jpg
76cfcb16bf016e1e059258aeb7ff3df9
0185430354c509b4f0cf51186c2b6e5222d9cedc
1925 F20110109_AACOZA vinch_p_Page_30.txt
5ee945a4a6d6d9deb2a2e6f99c3feacf
018c7c1b47639ef5838808e479e889f4449e00a9
177246 F20110109_AACPBB vinch_p_Page_21.jpg
f724b0b05bf5ff473b8e24ab3b25b7e2
e19dff2ab0e4bfad62eb17a45951fac355e7e4d7
61723 F20110109_AACOUD vinch_p_Page_45.jp2
5bfbaa58ee44275598cc361a3596ea1c
3787ce871a6de734387ec62f9f63bbfd7eaf8b55
205126 F20110109_AACOPH vinch_p_Page_60.jpg
9d68e822d1cb0f46717079a8632d0e40
67bab18bb3556788ecb9cb1ca8144f1113baa0f7
4224 F20110109_AACOZB vinch_p_Page_03thm.jpg
37faa699367ef23063e78684a5a1fe79
0f1c5ef0634fed0cd68d87536c319f3be42eb243
209084 F20110109_AACPBC vinch_p_Page_23.jpg
0eada986a30519a838b0220426a10aee
8086fccaeb12be6a97982b98ba91570f10c0a69b
1976 F20110109_AACOUE vinch_p_Page_63.txt
dca594824bc9f0d00a23e5b72a2f34eb
27ddee652b987cdff09aff3e852bb5bd01c601be
3410 F20110109_AACPGA vinch_p_Page_58.txt
8d3d131651ebe22af6120e424a1387dc
4929305193d977820bc1362c79950bc5cc793bde
20871 F20110109_AACOPI vinch_p_Page_77thm.jpg
fdaf85eb283975151d576efcc6eae54f
2b7d745c23e1a233779556accf193d77f9ae802e
31869 F20110109_AACOZC vinch_p_Page_05.jp2
b7cf2b35e1c886d73c2c20fe63b4d733
ce0a1912b9d66af975ba45b50290b94a8ced324e
43624 F20110109_AACOUF vinch_p_Page_43.pro
3bfb55f9babc8ea0d43918425d31e74d
877157b61b6c1ad37d49bbd9e2126e369db8d786
867 F20110109_AACPGB vinch_p_Page_59.txt
9a765625aa35dd415f4d2fa48cc686a3
c2eb0deb626f114b0e44a642f71c1518e6a223a8
87945 F20110109_AACOPJ vinch_p_Page_62.QC.jpg
1b94407c646ea524df6bcb5311ed8ddc
43c037983f64c2a4110ba0eae92a352156607a9c
F20110109_AACOZD vinch_p_Page_58.tif
8ab04ac2415b8bb5989b335bd31b96dd
42e4a056cf120e5f9be420aa84687eb3d563f3e9
177210 F20110109_AACPBD vinch_p_Page_26.jpg
02fd9e7b0ffb7a4a6631607717575cd1
02047d7520d035baf0883db47c10e2e657e17c43
53256 F20110109_AACOUG vinch_p_Page_31.QC.jpg
94e2f229b9cba6d5f6a7a7ebfad97b12
48082cd31dd3ea005480e7feb174d053c6dc9f6b
1422 F20110109_AACPGC vinch_p_Page_62.txt
efbd9eadbc795d5288f9881863eb3662
b7489d1cfeb55f375c4259a768a957be82a674ff
54133 F20110109_AACOPK vinch_p_Page_13.pro
8ccb2d9ab09121911d569d2a50dadf75
e02b5a7aca3f5badf67a5850828d8d8909e7f930
F20110109_AACOZE vinch_p_Page_30.tif
d94ba36d0fbf49fe4dca439d1d986d21
5cd9ffcc4481455c2f8c203ffe6d55658493d9c9
150835 F20110109_AACPBE vinch_p_Page_28.jpg
032c142afd767de25508dbf7681b3d3b
fd70a25bcda84a9b78a6e3f67fa1fd0bb85387dd
45236 F20110109_AACOUH vinch_p_Page_09thm.jpg
ae11d91c46bf111a39c8fadef699b58f
7a90b63bf8d062746f8d164ca6a879960783f4e2
1881 F20110109_AACPGD vinch_p_Page_64.txt
6553b35c1b2203c01e0f8b73c34a43c1
f104d8379a8cb30a93d3a162567268e9e49c1b17
78449 F20110109_AACOPL vinch_p_Page_16.QC.jpg
8252e74c76bd25a06c41f4d4ae55755e
538a8e9457719ed709a455559e6c91ff8595267e
1051859 F20110109_AACOZF vinch_p_Page_83.jp2
8cf60b9a8586750e88a45c8ac51bb1a2
1c95eb228c8e56502ddcd25680aabc875ff5e3e9
181231 F20110109_AACPBF vinch_p_Page_38.jpg
3cad2db4f8535feaefd4392071362ee9
a8ba2df3a112df24c05ad31089b419573f159309
81418 F20110109_AACOUI vinch_p_Page_35.jp2
01f6ab6a75a24bf5927d51ce2ce6c6d5
2199f2ffa850db80c71d4a72123e7eb86679cf9e
1746 F20110109_AACPGE vinch_p_Page_66.txt
0341244a451dfbe1910aa965fa7a4c6a
3259c2694263f12f6f01972d9475e223040af480
861 F20110109_AACOPM vinch_p_Page_74.txt
0a0f062a8542a9fdc33054bca188cdd2
1db515e0cd314a701f9ddcc865e6bad5e3aaccc8
48775 F20110109_AACOZG vinch_p_Page_30.pro
6f2b8b307f6a589a94d1a78c6f198eb4
b49907437fdd0cb6aed8407d3d71377f61e9e9b4
186400 F20110109_AACPBG vinch_p_Page_43.jpg
6c46e18f51f7e9e4561511b0c28c85ea
7b00c3b27fa3bf392897077affd438f935275fe1
2010 F20110109_AACOUJ vinch_p_Page_70.txt
01079e3c7829a43a28648542a5910944
4de7031f901a1d8fec71d297bb862014c6eeed8d
1162 F20110109_AACPGF vinch_p_Page_67.txt
6acf09ad527d802d6a219484db93f4ca
f3179f5f1bdaaceac47f4c99e4ad18109b1c1dc0
9508 F20110109_AACOPN vinch_p_Page_74thm.jpg
f9255bb9169800c4fc906d65f95de643
72d066dcc690f3620725a22184d016a4f7ac623d
624870 F20110109_AACOZH vinch_p_Page_55.jp2
47dddeb63d5ee8b2421c9a506832a2e3
6990a8681ed0774738d4df79825975c32a6eee8c
137464 F20110109_AACPBH vinch_p_Page_44.jpg
6fd7a9a80de1a3a074d316b7ea554584
35e8b169218bd2e33c44bc2723e38e2ce7aab2b2
45572 F20110109_AACOUK vinch_p_Page_83thm.jpg
531bd10247d732ec86a06023c868a1d7
808fd5ddfeb2474762334c42ed33a938f7862b95
2015 F20110109_AACPGG vinch_p_Page_68.txt
9c087b7d72f194f9443c11db30ac7d9a
2d9d63562e1e7bfee09d34d52fffd8fef5f2d067
18697 F20110109_AACOPO vinch_p_Page_75.pro
f5be69f0da516583f51036c1975deee2
e843489e7dcadf6ce33f866603b1ac3069c887d8
188128 F20110109_AACOZI vinch_p_Page_58.jpg
1ec38d3d65137546576018a251386a2c
3a8da7a2977e6e69395dc8b899eadabd7c54b18a
149967 F20110109_AACPBI vinch_p_Page_48.jpg
2922b246cd770f8814b2bc3a9cf92846
5eafbd07867466aa004718259e401cdf86efdba7
24441 F20110109_AACOUL vinch_p_Page_42thm.jpg
a9a7c0ea12118a03ab4fcfdd258d6f97
6e7abd712ed74e661a51b8f2a645c0907c4452fa
1300 F20110109_AACPGH vinch_p_Page_72.txt
3baf48a25b36b8f103ea3fa56b6af1d8
da5bc78c8184bdacebb05490b4699567fd57ba23
249409 F20110109_AACOPP vinch_p_Page_67.jpg
fb961ee2217f15bee34e00c0a9f9ed7d
f65bb356827ee8f4ef45e8050984a33bcc7a8a0d
620347 F20110109_AACOZJ vinch_p_Page_84.jp2
b3dc9e30913dcefc0ef983444c9cf21f
c65c7763e0d5f638f8910f730375354b6386de37
165359 F20110109_AACPBJ vinch_p_Page_52.jpg
b1fdefe7977e928be78260cb752bd0f8
59507a04e4ffa51a9ebd765e936fb230c909be40
40969 F20110109_AACOUM vinch_p_Page_10.pro
89b1a3dd7508777c06f1e880674f8c24
0f6d54637aeb0594013f4dd01fdebf8c07b21593
F20110109_AACOPQ vinch_p_Page_07.tif
baa5acc7b82f975038dcea67851d7c42
03fb2948e575008485501472a62b1d4b386969ed
8954 F20110109_AACOZK vinch_p_Page_82thm.jpg
8d8b75ac15c4c75e2b9b706505a0ede2
d4dfbc63bcfa633ac6de7f486076c84c8841814b
127523 F20110109_AACPBK vinch_p_Page_53.jpg
c4e658a80dd6a58fed69103f14735627
c15ffba53c7a15bb31cfd76ef4ccf17cad1fbdad
29867 F20110109_AACOUN vinch_p_Page_62.pro
91e345a5414cf370e9c6512a21add81e
87b8d3b19f13e02f3b267a084e9efac2d71d99d7
1542 F20110109_AACPGI vinch_p_Page_73.txt
6df8d6721aefb7052ac6297d7bfa52f3
73c258394408dda8f9c355e5739e4ce4ecff73c8
F20110109_AACPBL vinch_p_Page_61.jpg
919ccf87ad082c6b470936566a2a9d4c
02fdacbd8fec8501f9a91923483d31bea052ad50
74376 F20110109_AACOPR vinch_p_Page_55.QC.jpg
02af78dd288223da5f66d733aa5fc8cd
668245d19f64540019b7048a4d1cd0eb5fdc1c1b
F20110109_AACOZL vinch_p_Page_27.tif
b21d49ec926ea82d8f099750d41d4b08
fa01754314b8c66f73b62f138830c650d3b485bb
1832 F20110109_AACOUO vinch_p_Page_31.txt
849b7afd60670265328e3900022c670f
ae8661bc9cfc5ec915ef907dec9105c05b796a7a
913 F20110109_AACPGJ vinch_p_Page_75.txt
bb2c96158d6c4563c27a8449399c7fd2
bf32f9bc7c1a94bba7f1759b806c7359580e7d81
192566 F20110109_AACPBM vinch_p_Page_62.jpg
c54c514d50fbca6390f160f685c977e7
b76aabd7fa3985704befaa4f44123a3aae8db25b
184355 F20110109_AACOZM vinch_p_Page_32.jpg
ebb75d1f162d473e74e8ad5870fb1cf1
298cdeecb449660a55396965eec71dc9611bf6b8
38728 F20110109_AACOUP vinch_p_Page_64.pro
e646564daf6d7c3069691180ecdffc29
98b5ab2642021db8c011569b6a9a46e9342b163b
1186 F20110109_AACPGK vinch_p_Page_76.txt
f98d7429496793537d8644f066854496
2b596f3c2a87b915a46420c6d2494e01f2565292
213413 F20110109_AACPBN vinch_p_Page_68.jpg
5a899711ffe16202c9972102e021e293
c224ecb5652a3bb482bd8cce996fbfde2f677e91
1051961 F20110109_AACOZN vinch_p_Page_59.jp2
6f21b6953d5fa2216617db4461ebc41d
ec030020ad0831608aa07dc5b769e1013d6ac760
173176 F20110109_AACOUQ vinch_p_Page_39.jpg
e4aeb4a19f5c0796a96a9f940cf5ff75
bbbb68e9a9f5b1be45e55225c3536ed902323645
3090 F20110109_AACOPS vinch_p_Page_06.txt
cfed79127bf2d2a6aab330da8dd94392
4322ee14ffb9677edb9183d1fec34249dbf5cc1d
1767 F20110109_AACPGL vinch_p_Page_77.txt
a15eee4ba74f627075221b95c4a137b6
3431b0adbf01ae56c19658c27545b8e4ca009375
215748 F20110109_AACPBO vinch_p_Page_69.jpg
51887a27192646a0304629379d27bb63
7879e35e3846bcf331a905e6df4f0184f6d4f853
1405 F20110109_AACOZO vinch_p_Page_37.txt
929d122c6d86c19f07e4390920a3fc40
23f5ec506a50d560c3e24305d81e40d2cff3bafb
84939 F20110109_AACOUR vinch_p_Page_74.jpg
4a76e1427ea04937717e745756fc988c
b38ccbf0e9f27ba834e94ebd869678ee47789924
1051938 F20110109_AACOPT vinch_p_Page_67.jp2
3c97489d72b9eb4ca84ed79cd48c6d8f
817925962a61e39e8d1bcb2d83ff234dcaec5441



PAGE 1

DESIGN AND IMPLEMENTATION OF AN INTELLIGENT PRIMITIVE DRIVER By PETER M. VINCH, JR. A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2003

PAGE 2

Copyright 2003 by Peter M. Vinch, Jr.

PAGE 3

What we call the beginning is often the end. And to make an end is to make a beginning. The end is where we start from. T.S. Eliot, Four Quartets

PAGE 4

ACKNOWLEDGMENTS There are many individuals, on professional and personal fronts, whom I would like to thank for making possible the preparation and completion of this thesis. Professionally, I would like to thank Dr. Carl D. Crane, III (my academic advisor and chair of my graduate committee) for his direction, advice and encouragement. I also greatly appreciate the time and energy that the other members of my supervisory committee (Dr. John K. Schueller and Dr. Eric M. Scwartz) dedicated to my cause. I would like to extend my gratitude to the Nuclear and Radiological Engineering Department of the University of Florida for allowing me the use of their Remotec Andros robot for testing purposes. I thank the U.S. Department of Energy (Grant #DE-FG04-86NE37967) and the Air Force Research Laboratory located at Tyndall Air Force Base, Florida (contract # F08637-00-C6008) for all of their support. I am also grateful to the entire staff of the Center for Intelligent Machines and Robotics, for all of their assistance with the completion of my thesis. Additionally, I would like to distinguish the contributions of Shannon Ridgeway, Daniel Kent, Carl P. Evans, III, and especially Dr. David Keith Novick for all of their professional advice and the friendship that they have extended to me. Without these individuals, none of this would have been possible. Personally, I would like to thank all of my friends and family for their efforts to keep me sane and functional. Key people in this effort were Andrew and Gretchen McGraw, whose friendship, support and love I will always value. I would also like to thank Adam Feinberg for being such a great roommate, lifting partner, and best friend. He has pushed iv

PAGE 5

me to become better in every aspect of my life; and for this I will always be grateful. Of course, without the love and support of my family, all of my efforts would be fruitless. Therefore, I would like to thank my mother, Nancy; my two sisters, Bridget and Melissa; and my grandfather, Philip. Finally, I would like to thank my father, Peter M. Vinch, Sr.; and my uncle, Robert Frie. These men have been my greatest influences, helping to place me on the proper path through life. Without them, I would have been lost. v

PAGE 6

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iv LIST OF TABLES...........................................................................................................viii LIST OF FIGURES...........................................................................................................ix ABSTRACT.......................................................................................................................xi CHAPTERS 1 INTRODUCTION AND BACKGROUND....................................................................1 1.1 Introduction...............................................................................................................1 1.2 Background...............................................................................................................1 1.2.1 Assisted Teleop Control..................................................................................1 1.2.2 Stair Climbing.................................................................................................3 1.3 The Joint Architecture for Unmanned Systems (JAUS)...........................................4 1.3.1 Overview.........................................................................................................4 1.3.2 System Topology.............................................................................................6 1.3.3 The JAUS Component.....................................................................................7 1.3.4 The JAUS Message.........................................................................................7 2 TEST PLATFORM DEVELOPMENT.........................................................................10 2.1 Remotec Andros Robot...........................................................................................10 2.2 Andros JAUS Controller.........................................................................................12 2.3 Sensor Systems.......................................................................................................15 2.3.1 Stair Counter Assembly.................................................................................15 2.3.2 Auxiliary Track Positioning System.............................................................20 2.3.3 JAUS Positioning System.............................................................................21 2.4 Operator Control Unit.............................................................................................22 3 INTELLIGENT PRIMITIVE DRIVER DEFINITION AND APPLICATION............24 3.1 Component Definition............................................................................................24 3.1.1 Component Function.....................................................................................24 3.1.2 Component I/O..............................................................................................24 3.1.3 Component Description.................................................................................25 vi

PAGE 7

3.1.4 IPD Input and Output Messages....................................................................27 3.1.4.1 "Set Auxiliary Actuators"...................................................................27 3.1.4.2 "Query Auxiliary Actuators"..............................................................28 3.1.4.3 "Report Auxiliary Actuators".............................................................28 3.1.4.4 "Set Behavior X"................................................................................28 3.1.4.5 "Query Behavior X"...........................................................................29 3.1.4.6 "Report Behavior X"..........................................................................29 3.2 Intelligent Primitive Driver Application.................................................................30 3.2.1 Fuzzy Logic...................................................................................................30 3.2.2 Functionality..................................................................................................31 3.2.3 Program Logic...............................................................................................32 3.2.4 Ascend Protocol 1.........................................................................................39 3.2.5 Ascend Protocol 2.........................................................................................39 3.2.6 Descend Protocol 1........................................................................................41 3.2.7 Descend Protocol 2........................................................................................42 4 TESTING AND RESULTS...........................................................................................43 4.1 Stair-Counter Assembly..........................................................................................43 4.1.1 Testing Procedure..........................................................................................43 4.1.2 Results...........................................................................................................46 4.2 Auxiliary Track Positioning System.......................................................................48 4.2.1 Testing Procedure..........................................................................................48 4.2.2 Results...........................................................................................................50 4.3 Heading Alignment Controller...............................................................................52 4.3.1 Testing Procedure..........................................................................................52 4.3.2 Results...........................................................................................................52 5 CONCLUSIONS AND FUTURE WORK....................................................................55 5.1 Conclusions.............................................................................................................55 5.2 Future Work............................................................................................................59 APPENDIX A. STANDARD JAUS MESSAGES................................................................................61 A.1 Query Global Pose.................................................................................................61 A.2 Set Wrench Effort..................................................................................................61 A.3 JAUS Core Message Set........................................................................................63 B. STAIR COUNTER MATHEMATICAL DEVELOPMENT.......................................64 LIST OF REFERENCES...................................................................................................69 BIOGRAPHICAL SKETCH.............................................................................................71 vii

PAGE 8

LIST OF TABLES Table page 1-1 Message header data format.......................................................................................8 3-1 User defined input and output JAUS commands......................................................25 3-2 Set Auxiliary Actuators command fields..............................................................27 3-3 Query Auxiliary Actuators command field...........................................................28 3-4 Set Behavior X command fields...........................................................................29 3-5 Query Behavior X command field........................................................................29 3-6 "Set Behavior" 1 and 2 control data.........................................................................32 A-1 Query Global Pose data field...............................................................................61 A-2 Set Wrench Effort data fields...............................................................................62 A-3 Core message set......................................................................................................63 viii

PAGE 9

LIST OF FIGURES Figure page 1-1 Architecture hierarchy................................................................................................7 1-2 Message header properties bit layout.........................................................................9 2-1 Remotec Andros robotic platform............................................................................10 2-2 Andros physical dimensions.....................................................................................11 2-3 Native Andros controller..........................................................................................12 2-4 Communicator-Node Manager component interaction............................................13 2-5 Primitive Driver component interaction...................................................................14 2-6 Vehicle orthogonal coordinate system.....................................................................15 2-7 Stair counter assembly..............................................................................................16 2-9 Median filter example...............................................................................................18 2-10 Auxiliary track position system setup......................................................................20 3-1 Intelligent Primitive Driver implementation............................................................26 3-2 Intelligent Primitive Driver logic flow diagram.......................................................33 3-3 Set Auxiliary Actuator algorithm..........................................................................34 3-4 Opening sequence of Set Behavior X algorithm...................................................35 3-5 Stair data representation...........................................................................................36 3-6 Skew alignment task correction................................................................................37 3-7 Ascend stair motion protocol....................................................................................40 3-8 Descend stair motion protocol..................................................................................41 4-1 Calibration data for Sharp GP2D12 infrared object detectors..................................44 ix

PAGE 10

4-2 Stair-counter testing assembly..................................................................................45 4-3 Stair-counter data......................................................................................................47 4-4 Plumb compass attached to Andros auxiliary track..................................................48 4-5 Controller commanded halt angle and actuator halt angle versus operator commanded angle....................................................................................................50 4-6 Controller commanded halt error and actuator halt error versus operator commanded angle....................................................................................................51 4-7 Controller commanded halt heading and vehicle halt heading versus operator commanded heading................................................................................................53 4-8 Controller commanded heading error and vehicle heading error versus operator commanded heading................................................................................................54 5-1 Controller mounted on Andros platform..................................................................56 B-1 Stair representation...................................................................................................64 B-2 Stair runner model.....................................................................................................65 B-3 Stair riser model........................................................................................................67 B-4 Calculated distances, d, for varying value of .........................................................68 x

PAGE 11

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science DESIGN AND IMPLEMENTATION OF AN INTELLIGENT PRIMITIVE DRIVER By Peter M. Vinch, Jr. August 2003 Chair: Carl D. Crane, III Department: Mechanical and Aerospace Engineering An Intelligent Primitive Driver (IPD) was designed to supplement the control of a Primitive Driver component that is defined in the Department of Defense Joint Architecture for Unmanned Systems (JAUS). Whereas the Primitive Driver component accepts and blindly executes wrench commands, the IPD uses various subsystems to provide it with the necessary information to make low-level decisions concerning vehicle control. The IPD is accessible by either an onboard autonomous control system; or by a tele-operational control system. Tele-operational control (teleop) is characterized by the direct control of a platform by a human operator. For the case of an autonomous control system, the IPD reduces high-level control responsibilities; and therefore reduces processor demands. In the case of teleop control, the IPD serves to ease operator burden by automating intensive operator-controlled processes. The test platform for the functionality of the Intelligent Primitive Driver was a Remotec ANDROS robot. In the case of the ANDROS robot, the IPD automates the process of maneuvering up or down a flight of stairs. xi

PAGE 12

CHAPTER 1 INTRODUCTION AND BACKGROUND 1.1 Introduction The purpose of this research was to design and develop an experimental intelligence component based on the Joint Architecture for Unmanned Systems (JAUS), currently being developed in concert with the Department of Defense. This component will be designated the Intelligent Primitive Driver (IPD) and will allow for assisted tele-operational (teleop) control of a platform. Teleop control can be defined as the control of a vehicle or robot by the direct input of a human operator. Assisted teleop is based upon this concept, but includes additional computer control to supplement the operators control; intensive control procedures were automated to ease the burden on the operator. The IPD accomplished this task by having direct control of any and all actuators that directly affect the motion of the platform. A Remotec Andros robot, outfitted with a JAUS-compliant controller, was used to test the viability of the IPD. In the case of the Andros, the IPD automated the complicated stair ascending and descending operations. 1.2 Background 1.2.1 Assisted Teleop Control The human-machine relationship has always been clearly defined: machines are controlled by humans and are constructed to ease the burdens of human life. However, two recently developing factors have begun to dramatically change this relationship. 1

PAGE 13

2 First, an increase in computing power and system reliability along with a decrease in size and power requirements of modern control systems have made possible the shift of some control responsibility from the human operator to the controller itself. Bayouth and colleagues [1] (of the Robotics Institute of Carnegie Mellon University) constructed an autonomous roadway vehicle that demonstrated lane following, speed and heading compliance, and obstacle avoidance in an effort to increase vehicle safety and mobility. Several other groups have also worked on the Intelligent Cruise Control concept. The Mustererkennung und Szenenanalyse Pattern Recognition and Scene Analysis (MESA) research group [2] have developed behaviors (such as tracking a lead vehicle or lane changing) that comprise a basic control set on which more complicated procedures are based. Schlegel [3], in his thesis, Autonomous Vehicle Control using Image Processing, tested the intelligent cruise control notion through the use of scale models coupled with a remote control station aimed at emulating full-scale vehicle controls. The second factor that has influenced the human-machine interface is the growing complexity of the platforms being automated and the tasks they are able to perform. Connell and Viola [4] (of the IBM T.J. Watson Research Center) have a novel way of describing the problems with traditional platform control systems: Consider the differences between riding a horse and driving an automobile. A horse will not run into a telephone pole at high speed. If you fall asleep in the saddle, a horse will continue to follow the path that it is on. In general, horses are much smarter than automobiles and thus provide a better model for control of a mobile robot. [4] Connell and Viola constructed a platform and control system that cast the operator as an agent in the control system, able to input commands into the arbitration network, as well as a high-level command language that was able to shut out individual control agents.

PAGE 14

3 Huntsberger and Rose [5], of the Jet Propulsion Laboratory (JPL) and the University of South Carolina (USC), respectively, are working on a behavior-based control system named BISMARC, or the Biologically Inspired System for Map-based Autonomous Rover Control, for use with the Mars rover platforms. They utilize a form of path planning that is derived from the study of human navigation through complex environments. 1.2.2 Stair Climbing For mobile robotic platforms to be useful in urban environments, they need to be able to easily traverse commonly found terrain features, such as stairways. Several detection methods are used to enable platform navigation on these non-continuous planar structures (such as vision-based positioning and edge detection, laser-based edge detection, and the fusion of several sensor systems). Others have solved the dilemma by manipulating the physical characteristics of the platform to suite the special needs of a stair-climbing vehicle. Matthies, et al. [6] constructed a small mobile platform capable of performing reconnaissance duties in urban situations. To meet the stair climbing requirements associated with this detail, a vision-guided navigation and detection system was implemented on the robot. A stereovision system was used to detect the forward edges of individual steps. This information was used to derive the angle of rotation between the robot and the stairway; and to ensure that the robot was accurately following the stair heading. Lewis and Simo [7] (Iguana Robotics, Inc.) built a bipedal platform based on the biomorphic concept capable of stair travel (Figure 1-1). Basically, a biomorphic robot attempts to mimic the sensory capabilities of animals; sensory input is predicated upon

PAGE 15

4 voluntary movement of the platform and must be distinguished from possible inputs produced by the platform itself. The platform fused stereovision; and tactile and pressure sensors to build an accurate data model of the terrain to traverse. Another application of the biomorphic concept is the work of Talebi, et al. [8]. They constructed a quadruped platform that has only one actuator per leg coupled with compliant prismatic joints. Therefore, as an animal would, the platform climbs a stair dynamically. As the leg contacts the stair, ground forces cause the joint spring to compress; and the effective length of the leg is reduced. Perhaps the most stable solution for the stair-climbing problem, when the development of the platform permits, is to tailor the geometry to accommodate the stair climbing motion. Lauria, et al. [9] took this approach in developing their vehicle, Octopus. The platform consists of eight motorized, tactile wheels and a tilt sensor; and has a total of fifteen degrees of freedom. The platform geometry allows for all eight wheels to be in contact with the ground at all times, regardless of the terrain profile; allowing for relatively simple travel of the platform across any uneven terrain, stairways included. 1.3 The Joint Architecture for Unmanned Systems (JAUS) This section provides a functional description of the Joint Architecture for Unmanned Systems (JAUS). The technical constraints on the architecture, system topology, standard component definition, and the JAUS message will be discussed. 1.3.1 Overview The JAUS architecture is being developed in conjunction with the Department of Defense in support of unmanned vehicle systems development and provides a means for reducing system life-cycle costs by offering a well-defined component interface. This

PAGE 16

5 interface allows for the future reuse of expensive components in developing autonomous systems and also allows for the quick exchange of malfunctioning or outdated components in current autonomous systems. Further, the engineer is free to place all available resources into obtaining optimal performance from the component as its interface is predefined [10]. The JAUS architecture is divided into three separate volumes: the JAUS Domain Model, Document Control Plan, and Reference Architecture. The JAUS Domain Model defines both known and prospective operational requirements of unmanned systems, while the Document Control Plan describes the procedure used to recognize and track changes to accepted JAUS documents. This work will focus solely upon the Reference Architecture as it is concerned with aspects of component design. The reference architecture defines components, messages and standards that classify a system paradigm, which allows for the assimilation of distributed system architectures. The reference architecture is comprised only of components and messages that have been technically evaluated by the tech base, academia, or an industry source and whose implementation is thoroughly understood. Therefore, the incorporation of components, their classification, and their corresponding messages is an evolutionary process [10]. There are four technical constraints, which have been levied upon the JAUS architecture to ensure that it may be freely applied to any classification of unmanned system. These constraints are platform independence, mission isolation, computer hardware independence, and technological independence. To be platform independent, no assumptions concerning vehicle platforms to be automated will be incorporated into the definition of any JAUS component. The JAUS architecture defines a mission as the

PAGE 17

6 ability to gather information about or to alter the state of the environment in which the platform is operating. Therefore, the mission isolation constraint is intended to allow the engineer to construct systems that can support a variety of missions, not just a single one. The computer hardware independence constraint insists that the component be designed independent of the computer system upon which the component will run. This was included in the architecture so that currently used components can be applied to future computer systems without modification to the component. This allows new computer architectures to be easily inserted into current systems, extending its life cycle. This also allows for hardware flexibility, as the appropriate hardware may be applied to each system. Finally, technological independence is similar to computer hardware independence, but instead deals with the action to be performed by the component instead of the system that is performing the action. This constraint basically states that the architecture will make no assumptions concerning the method by which an action is performed. For example, in a JAUS compliant position system, no assumptions are made concerning the method in which the vehicle position is obtained. Any method of obtaining vehicle position is allowable, from a Global Positioning System (GPS), dead reckoning, inertial measurement, a vision based position system, or any subsequent positioning system [10]. 1.3.2 System Topology There are four elements, which comprise the hierarchy of the JAUS architecture: the System, Subsystem, Node, and Component/Instance. A System is a logical grouping of one or more Subsystems, which have been grouped such that beneficial cooperation between the Subsystems can be achieved. A Subsystem is a distinct organism, which is comprised of any number of Nodes necessary to form a complete unmanned system. A

PAGE 18

7 Node is a distinct entity, comprised of a single processor or multiple processors working in conjunction with each other, to provide a complete service. Finally, a Component is a cohesive software process, which runs on a Node. An Instance is a single occurrence of a Component running on a Node. Several Instances of the same Component may run on a single Node, and are delineated by unique addresses. Figure 1-1 illustrates the interaction of these four levels [10] SYSTEM Subsystem Subsystem Subsystem Node Node Node Node Comp1, Inst1 Comp2, Inst1 Comp2, Inst2 CompN, Inst1 Figure 1-1: Architecture hierarchy (used from JAUS: Reference Architecture Specification, pg. 12) 1.3.3 The JAUS Component As JAUS is a hierarchical system of components with standardized interfaces, the JAUS Component is a strictly defined entity. A distinct name and identification number defines a JAUS Component and every JAUS Component shall perform a single, cohesive function. Each Component must be able to accept and act upon the set of core JAUS command codes, as well as the input and output codes specific to the individual Component itself. A list of the core JAUS command codes may be found in Appendix A [10]. 1.3.4 The JAUS Message A JAUS message is comprised of two distinct components: the message header and the message data buffer. The message header completely defines the messages

PAGE 19

8 destination node, component, instance and subsystem identification, and the messages corresponding source information. The message header also consists of the JAUS command code, the number of bytes in the data buffer that the destination component can expect to receive, and information pertaining to the message properties, such as the JAUS architecture version being used. The message header data is found in Table 1-1 while the bit field layout for the message properties can be seen in Figure 1-2. Table 1-1: Message header data format (used from JAUS: Reference Architecture Specification, pg. 54) Field # Field Description Size (Bytes) 1 Message properties 2 2 Command code 2 3 Destination instance ID 1 4 Destination component ID 1 5 Destination node ID 1 6 Destination subsystem ID 1 7 Source instance ID 1 8 Source component ID 1 9 Source node ID 1 10 Source subsystem ID 1 11 Data control (bytes) 2 12 Sequence number 2 Total Bytes 16 The message data buffer is composed of packed JAUS control data. Each command code has control data associated with it that is used by the system to command component behavior. In an effort to reduce the size of the JAUS messages being transmitted, and therefore reduce the required bandwidth of the system, the message data is compressed before being transmitted. To accommodate this, the JAUS code library for

PAGE 20

9 each component and its subsequent command codes must have the ability to pack and unpack the control data. Message PriorityRange 0..15Default Priority 6Normal Priority Range 0..11Safety Critical Range 12..15 ack/nak0 -None, 1 -Request ack/nak2-nakresponse 3 -ackresponse 76543210Most significant bitLeast significant bit Service Connection Flag1 -Service Connection, 0 -Not Experimental Message Flag0-JAUGS, 1 -Experimental VersionRange 0..63Version 2.0 = 0Version 3.0 = 12..63 unused8 Reserved131415 Reserved Message PriorityRange 0..15Default Priority 6Normal Priority Range 0..11Safety Critical Range 12..15 ack/nak0 -None, 1 -Request ack/nak2-nakresponse 3 -ackresponse 76543210Most significant bitLeast significant bit Service Connection Flag1 -Service Connection, 0 -Not Experimental Message Flag0-JAUGS, 1 -Experimental VersionRange 0..63Version 2.0 = 0Version 3.0 = 12..63 unused8 Reserved131415 Reserved Figure 1-2: Message header properties bit layout (used from JAUS: Reference Architecture Specification, pg. 54)

PAGE 21

CHAPTER 2 TEST PLATFORM DEVELOPMENT To investigate the Intelligent Primitive Driver, a test platform first needed to be outfitted with a JAUS compliant control system. Due to the availability of indirect motion actuators on the system and its relatively complicated stair climbing procedures, a Remotec Andros robot was chosen for this task. 2.1 Remotec Andros Robot Figure 2-1 depicts the Remotec Andros robot. As stated in the instruction manual, the primary design purpose of the Andros is to provide an effective means for remote Explosive Ordnance Disposal (EOD) Andros robots are currently used to remotely perform a variety of hazardous work tasks including explosive handling, tactical support operations, and nuclear plant maintenance [11]. Figure 2-1: Remotec Andros robotic platform The robot consists of a main chassis, front and rear sets of auxiliary tracks, and the main arm assembly. The tracks are made of Kevlar belts with molded internal and external urethane cleats. The auxiliary tracks are able to swing from +85 degrees to 10

PAGE 22

11 degrees relative to the horizontal position. The drive motors are able to propel the Andros up forty-five degree slopes or stairs and can maintain the vehicles position upon a slope through dynamic braking. The physical dimensions of the Andros are seen in Figure 2-2 [11]. Figure 2-2: Andros physical dimensions Figure 2-3 depicts the native Andros controller. Upon power up of the Andros system, the native control transmits an initialization string to the Andros embedded controller and then begins the continuous output of the control data. The Andros embedded controller will only enter the ready state and accept platform control data if the initialization string is properly sent and the control data is received at a maximum 5 Hz frequency. The controller uses a proprietary serial control stream to communicate with the Andros embedded controller. The update frequency is the absolute maximum rate at which any controller may update the control data being sent to the Andros and therefore alter the Andros intended motion. 3228 3228 To use the Andros robot as the test platform for the IPD system, the JAUS control system implemented on the Andros had to be completely removable from the system so that the native Andros controller could be reconnected and used to control the Andros.

PAGE 23

12 To meet this interoperability constraint, the JAUS control system mimicked the serial control stream of the native controller. To achieve this, the control stream and initialization string were reversed engineered from the output of the native controller; however, the specific information pertaining to the Andros control data bytes may not be disseminated because of a nondisclosure agreement entered into between the Center for Intelligent Machines and Robotics (CIMAR) laboratory, located at the University of Florida, and Remotec, the manufacturer of the Andros platform. Figure 2-3: Native Andros controller 2.2 Andros JAUS Controller The Andros JAUS controller operates on a RabbitCore RCM3200 microcontroller, which utilizes a Rabbit 3000 microprocessor running at 44.2 MHz. The RCM3200 has an integrated 10/100Base-T Ethernet port and six available serial ports for communications, as well as 44 configurable, 5 volt tolerant, I/O lines. The RCM3200 runs the Dynamic C Premier Version 7.33P3 real time operating system, in which the four basic JAUS components that comprise the Andros control system were coded.

PAGE 24

13 These components are the Communicator, Node Manager, Primitive Driver, and Position System. Libraries for each component were coded following the specifications found in the JAUS Reference Architecture. Component A Node Manager Communicator Communicator Node Manager Component B Ethernet Node ANode B Figure 2-4: Communicator-Node Manager component interaction Two JAUS components are directly responsible for all inter-component communications: the Communicator and the Node Manager. As such, all nodes must support both a Communicator and a Node Manager component. The Communicator allows for a single point of message entry into a subsystem while maintaining the data link between the subsystems. The Andros Communicator uses a User Datagram Protocol (UDP) Ethernet connection for all communications. The Node Manager component controls the routing of JAUS messages from one node to another. As depicted in Figure 2-4, a JAUS message is spawned within a component and then sent to the Node Manager, where the information pertaining to the destination component and destination node are attached to the message. This fully defined JAUS message is now passed on to the communicator, which handles the transmission of the message to the proper node [10].

PAGE 25

14 SystemCommander Primitive Driver CommandedWrench EffortVehicle SpecificActuator Commands Figure 2-5: Primitive Driver component interaction The Primitive Driver is a component, which accepts wrench commands from the System Commander and resolves them into vehicle specific actuator signals, thus initiating vehicle motion, as seen in Figure 2-5. A wrench command consists of six propulsive and six resistive elements, with each set consisting of three linear force elements and three rotational moment elements. These elements are then mapped to the three axis orthogonal coordinate system assigned to the vehicle, as shown in Figure 2-6. It is worth noting that every element of a wrench message is not necessarily applicable to every vehicle. For example, a wheeled vehicle typically only requires three elements of the wrench message to control it properly: the resistive and propulsive linear forces in the x direction and the rotational moment in the z direction [10].

PAGE 26

15 The Position System is concerned solely with the determination of the vehicles global position and orientation and is necessary for the controller to perform accurate autonomous motion. The vehicles position and orientation information is provided to the system upon receipt of a Query Global Pose command from either the Operator Control Unit or the Intelligent Primitive Driver. Ground Plane z y x Figure 2-6: Vehicle orthogonal coordinate system 2.3 Sensor Systems There are three main sensor systems used by the Andros system: the stair counter assembly, the auxiliary track position system, and the JAUS positioning system. These systems provide feedback essential to the controllers ability to execute behavioral commands. 2.3.1 Stair Counter Assembly For the stair-climbing algorithms to function properly, the control system needs to know the relative position of the Andros on the stairs. Typically, a Global Positioning System (GPS) would be used to provide location information in a robotic system. However, staircases are found in or around buildings, which generally limit the effectiveness of a GPS system; if satellite transmissions to the GPS receiver are blocked

PAGE 27

16 by the structure housing the staircase, no position information will be acquired. Therefore, the stair counter assembly was designed to provide the relative position of the Andros upon the staircase by counting the number of stairs that the Andros has passed and is able to account for a step while moving in either direction upon a staircase. For example, while climbing the stairs, the Andros passes four steps. While attempting to move to the fifth step, a slippage error occurs and the Andros slides back down two steps. The stair counter is able to take this error into account and update the current position of the Andros upon the stairs. In this case, the Andros would now be located at the second step. Figure 2-7: Stair counter assembly The stair counter assembly consists of an array of two Sharp GP2D12 infrared object detectors. These sensors take continuous distance readings up to 80 cm, have an update Infrared Sensors Shroud Mounting Plate

PAGE 28

17 rate of 31.25 Hz, and are interfaced by the RabbitCore microcontroller through the use of a TLC545 Texas Instruments analog-to-digital converter. The sensors are positioned one in front of the other with a one-inch offset and are orientated such that their detection beams are perpendicular to the long axis of the Andros, as seen in Figure 2-7; the sensors point directly at the plane upon which the Andros is situated. Both sensors are shrouded to limit the amount of interference they may receive from ambient light sources and from each other. -1.4-1.2-1-0.8-0.6-0.4-0.200.20.444.555.566.5Time (sec)Distance (in) Series1 Stair Data1st Derivative2nd Derivativ e Impulse Figure 2-8: Infrared sensor stair representation

PAGE 29

18 Each infrared sensor constructs a digital representation of the staircase as the Andros moves on it by determining the distance from the sensor to the staircase. By assuming that the vehicle maintains a relatively constant velocity upon the staircase, the derivative of the stair data can be found by simply taking the difference of the current data point and the previous data point collected. The second derivative of the stair data can now be obtained by taking the difference of the first derivative data. Figure 2-8 depicts a sample stair data representation for a single infrared detector and the corresponding first and second derivative data. The graph has been cropped to emphasize the range of pertinent data. The data for the stair representation was simulated using a mathematical model of the sensor system, with the first and second derivative data obtained as outlined above. For the simulation, the rise of a single step was set at 8 inches, the run was set at 10 inches, and a 0.1 second sampling rate was used. Derivation of the mathematical model of the sensor system can be found in Appendix B. 43549514334411445554559995445554 Sorted Data Filtered Data Raw Data Figure 2-9: Median filter example

PAGE 30

19 To account for noise in the infrared detection signals, the first derivative data is filtered using a three element median filter before the second derivative is calculated. Median filtering is a non-linear filtering technique useful for the suppression of impulse noise and the smoothing of edges. It works by taking a set number of data points and determining the mathematical median of them, which then replaces the data point. An example of a three element median filter is shown in Figure 2-9. In this example, three elements of the raw data are grouped together and sorted from low to high. In this configuration, the median of the data is simply the middle of the three numbers, which is now the filtered data point [12]. The impulses in the second derivative data represent inflection points on the stairs; the interior concave stair corner will yield a positive impulse while an exterior convex stair corner will yield a negative impulse. The system accounts for the stairs that the Andros has passed by detecting these impulses; if the impulse that is less than a given threshold value, a stair is counted. The direction of travel upon the stairs, and therefore whether to add or subtract a stair to the total number counted, is determined by which sensor detected the impulse first. If the front detector senses the impulse before the rear, then a stair is added. If the rear detector senses the impulse before the front, then a stair is subtracted from the total. The computation of the first and second derivatives of the stair representation and the application of the median filter induces a delay in the detection of the stair inflections. Each of the derivative computations account for a one-cycle delay, while the median filter accounts for a three-cycle delay for a total delay of five cycles. As the detectors are

PAGE 31

20 polled at a rate of 20 Hz, the total delay time is 0.25 seconds between acquisition of the stair data and detection of a stair inflection. The stair counter assembly also has an end of world capability, meaning that it can be used for detection of drop-offs and ledges. The system uses this function to determine the edge of a landing when descending a set of stairs. The edge is detected by monitoring the output of the infrared sensors: the distances measured will remain constant until the sensor reaches a point when it is directly over the first step. At this point, there will be a drastic change in the measured distance, which the system interprets as the edge of the landing and the beginning of the stairs. Figure 2-10: Auxiliary track position system setup Andros Chassis Auxiliary Track Assembly DWT Senso r Auxiliary Trac k Sensor Cable 65 o 150 o 0 o 2.3.2 Auxiliary Track Positioning System A Draw-Wire Transducer (DWT) sensor, manufactured by UniMeasure, is used to measure the angle of the Andros auxiliary tracks, one each for the front and rear tracks.

PAGE 32

21 This sensor was used over other forms of angular sensors, such as rotary or optical encoders, because of its ease of setup and robust mechanical interface; there are no gears to become jammed with dirt or optical sensors to become inoperable because of grime. The DWT is simply a spring-loaded potentiometer connected to a three-foot long cable. The DWT sensor is attached to the chassis of the Andros, with the draw cable being wrapped around the auxiliary track drum once and then attached to it via a 10-32 cap-head screw. The setup is shown in Figure 2-10. A 5-volt reference voltage is applied to the sensor, which will return from 0 to 5 volts proportional to the length of cable drawn from the sensor. The governing equation for the angle measured by the system is given in Equation 2-1, where V high and V low are the upper and lower voltage bounds observed by the sensor and V measured is the sensor voltage. The DWT sensors are interfaced by the RabbitCore microcontroller through the use of a TLC545 Texas Instruments analog-to-digital converter. 150*lowhighlowmeasuredVVVV (2 1) 2.3.3 JAUS Positioning System As there is no GPS being used on the Andros system, the position system is comprised solely of a PNI Corporation TCM2-20 tilt-compensated module to update the Andros heading. The compass heading of the Andros is filtered using a three element median filter, as previously described. The TCM2-20 is based upon PNI Corp.s proprietary triaxial magnetometer system and its biaxial electrolytic inclinometer. When level, it is accurate to within +/0.5

PAGE 33

22 degrees RMS with 0.1-degree resolution. This changes to +/1 degree RMS when the system is on an incline. It communicates via a 38.6 kBaud, RS-232 serial connection and is set to run at a sampling rate of 20 Hz. The digital compass experiences a computation delay, much in the same manner as the stair counter system. The three element median filtering produces a delay of three cycles, which corresponds to a delay of 0.15 seconds between acquisition of the heading data and realization of the filtered heading. 2.4 Operator Control Unit In order for the Andros JAUS control system to be fully operable, an Operator Control Unit (OCU) was developed on a Gateway Solo 3350 laptop with the Linux Redhat 8.0 operating system. A Netgear ME102 Wireless Access Point is used to establish a wireless Ethernet connection with the Andros JAUS controller. The access point uses the IEEE 802.11b standard and transmits up to 11 Mpbs at 2.4 to 2.5 GHz. To be able to communicate with the JAUS components located on the Andros platform, the OCU needed to have information pertinent to the construction of the JAUS messages required to command these components available. Therefore, JAUS message libraries for the Primitive Driver and Position System components were coded for the Linux operating system. These libraries were adapted from code obtained from Dr. Jeff Wit of Wintech, Inc. Communicator and Node Manager components were also coded for the Linux operating system to allow the OCU to interact with the Andros JAUS components. All of the OCU components were developed in parallel with the corresponding components used on the Rabbit microcontroller. The OCU console was developed using the Linux Curses library. This was chosen for the basis of the user interface because it allows for the easy manipulation of the

PAGE 34

23 terminal display regardless of the terminal type used. The Curses library only supports the use of single byte characters for display, but this was more than adequate to meet the needs of this OCU.

PAGE 35

CHAPTER 3 INTELLIGENT PRIMITIVE DRIVER DEFINITION AND APPLICATION This chapter defines the Intelligent Primitive Driver (IPD) in terms of the JAUS architecture. It then details the application of the Intelligent Primitive Driver to the Andros system. 3.1 Component Definition For the IPD to be considered a JAUS component, it needs to fit into the rigid framework that comprises the architecture. Therefore, the component will be defined as per the specifications detailed in the JAUS Reference Architecture: the component function, input and output messages, and description will be defined. The component has been assigned the component identification number of 99 [10]. 3.1.1 Component Function The Intelligent Primitive Driver component is responsible for the control of all indirect motion related actuators. An indirect motion related actuator is any actuator that affects the ability of a platform to perform a commanded motion, but does not perform that motion itself. For example, on the Andros robot, the front and rear auxiliary tracks are considered indirect motion actuators. They are responsible for aiding the Andros in moving over rough and uneven terrain, but do not directly produce the motion. 3.1.2 Component I/O The IPD will accept any of the JAUS core input and output messages, as well as the Set Wrench Effort and Query Global Pose commands. These commands are as 24

PAGE 36

25 defined in Appendix A. Table 3-1 shows the user defined set of input and output messages and their corresponding unique command codes. The input and output command sets will be completely defined in the Input and Output Commands section later in this chapter. Table 3-1: User defined input and output JAUS commands Command Code Description 0x1FF1 Set Auxiliary Actuator 0x1FF2 0x1FF9 Set Behavior X IN 0x3FF1 Query Auxiliary Actuator 0x3FF2 0x3FF9 Query Behavior X 0x5FF1 Report Auxiliary Actuators OUT 0x5FF2 0x5FF9 Report Behavior X 3.1.3 Component Description The IPD defines a command interface to control any available indirect motion actuators available upon a platform and any subsequent set of vehicle behaviors that would utilize these actuators. Further, the IPD is able to issue wrench commands to a primitive driver component. Automation of vehicle behaviors is accomplished to ease operator burden when the JAUS system is acting in tele-operational mode and to decrease high-level processor load when the system is acting in full-autonomous mode. Similar to the Primitive Driver component, the IPD does not imply any specific platform in its definition and therefore is not completely defined until it has been applied to the control system of a particular platform. Figure 3-1 illustrates the most basic implementation of the Intelligent Primitive Driver into the JAUS system architecture. The System Commander may send commanded wrench efforts to the primitive driver to initiate vehicle motion or any of the

PAGE 37

26 aforementioned IPD command codes to the Intelligent Primitive Driver either to control an indirect motion actuator or start a vehicle behavior. If a command is sent to begin a vehicle behavior, the IPD is able to send vehicle specific commands directly to the vehicle to control the indirect motion actuators. Also, if vehicle motion is necessary to accomplish the behavior, the IPD may send commanded wrench efforts to the primitive driver component to incite vehicle motion. System Commander PrimitiveDriverCommandedWrench EffortVehicleSpecificActuatorCommands IntelligentPrimitiveDriver Indirect MotionActuatorCommands Subsystem System CommandedWrenchEffortIPD Command PoseSystemQueryPose PoseData Figure 3-1: Intelligent Primitive Driver implementation

PAGE 38

27 3.1.4 IPD Input and Output Messages This section will define the set of user-defined input and output messages used by the IPD. 3.1.4.1 Set Auxiliary Actuators The Set Auxiliary Actuators message controls the indirect motion actuators available on the platform. The command consists of four available linear actuator fields and four available rotational actuator fields. Each field in the command may be mapped directly to a single actuator of corresponding type, either linear or rotational, for control. The interpretation of the numerical limits of the data fields allow for a wide array of actuator control. The limits may be interpreted as a percentage of the maximum speed to move the actuator at, a percentage of the maximum distance to move the actuator to, or even interpreted as a blind forward/reverse/stop control message. The data fields and vector-mapping table is for this command is found in Table 3-2. Table 3-2: Set Auxiliary Actuators command fields Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Mapping Table that Follows 2 Aux Actuator 1 Scaled Integer 3 Aux Actuator 2 Short Integer Percent Lower Limit: -100 4 Aux Actuator 3 Upper Limit: 100 5 Aux Actuator 4 6 Aux Actuator 5 Scaled Integer 7 Aux Actuator 6 Short Integer Radians Lower Limit: 8 Aux Actuator 7 Upper Limit: 9 Aux Actuator 8 Vector to Data Field Mapping for Presence Vector of Above Command Vector Bit 7 6 5 4 3 2 1 0 Data Field 9 8 7 6 5 4 3 2

PAGE 39

28 3.1.4.2 Query Auxiliary Actuators The Query Auxiliary Actuators message will cause the IPD to reply to the requesting component with a Report Auxiliary Actuators message. The command field is shown in Table 3-3. Table 3-3: Query Auxiliary Actuators command field Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Report Auxiliary Actuator Message 3.1.4.3 Report Auxiliary Actuators The Report Auxiliary Actuators command message provides the receiving component with the current values of the commanded Set Auxiliary Actuators message. The message data and mapping of the presence vector for the Report Auxiliary Actuators message are the same as the Set Auxiliary Actuators message, as seen in Table 3-2. 3.1.4.4 Set Behavior X The Set Behavior X message is used to initiate the behavioral control algorithms, which are to be applied to the individual platform. The message has been issued the command code range of 0xFFF2 to 0xFFF9 to allow for 8 vehicle specific behavior codes to be applied to the control system. The corresponding behavior number, from 1 to 8, replaces the X in the command code names in the code definition. The data fields are delineated into 4 unsigned integers and 4 full integers, giving the design engineer a wide range of available variables to transmit any necessary behavioral data to the system, such as latitude and longitude, heading, or distance to travel. As such, a specific behavior may

PAGE 40

29 be defined by all, some, or none of the available data fields. The data fields and vector-mapping table is for this command is found in Table 3-4. Table 3-4: Set Behavior X command fields Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Mapping Table that Follows 2 Behavioral Parameter 1 3 Behavioral Parameter 2 Unsigned Int N/A User defined fields 4 Behavioral Parameter 3 5 Behavioral Parameter 4 6 Behavioral Parameter 5 7 Behavioral Parameter 6 Float N/A User defined fields 8 Behavioral Parameter 7 9 Behavioral Parameter 8 Vector to Data Field Mapping for Presence Vector of Above Command Vector Bit 7 6 5 4 3 2 1 0 Data Field 9 8 7 6 5 4 3 2 3.1.4.5 Query Behavior X The Query Behavior X message will cause the IPD to reply to the requesting component with a Report Behavior X message. The command field is shown in Table 3-5. Table 3-5: Query Behavior X command field Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Report Behavior X Message 3.1.4.6 Report Behavior X The Report Behavior X command message provides the receiving component with the current behavioral data being performed by the platform. The message data and

PAGE 41

30 mapping of the presence vector for the Report Behavior X messages are the same as the Set Behavior X message, as seen in Table 3-4. 3.2 Intelligent Primitive Driver Application An Intelligent Primitive Driver component must be applied to a vehicle to fully define the functionality of the behavioral and auxiliary actuator controls as no vehicle specific data is given in the JAUS definition of the component. This section will discuss the four main areas that comprise the application of the IPD to the Remotec Andros test platform. These areas include: a discussion of the basis of the intelligence used in the control algorithms, the functionality of the component as it pertains to the Andros robot, an explanation of the program logic used in the controller, and an explanation of the stair motion algorithms used by the controller. 3.2.1 Fuzzy Logic Professor Lotfi Zadeh at the University of California in Berkley developed fuzzy Logic in 1965 as a method of processing data by allowing partial set membership rather than classical precise set membership or non-membership. Fuzzy Logic is based upon a human intelligence model; Professor Zadeh reasoned that people do not need precise, numerical information as input and yet they are capable of highly adaptive control. As intuitive as this approach of control may appear, it was not applied to an actual control system until the 1970s, mainly due to inadequacies in small-computer capabilities at the time [13]. Fuzzy Logic provides a simple way to arrive at a definite conclusion based upon vague, ambiguous, noisy or imprecise information. The logic model focuses on what a system should do rather than trying to understand how the system works and concentrates on the problem rather than attempting to represent the system mathematically, which may

PAGE 42

31 be impossible, especially in the case of nonlinear systems. Fuzzy Logic incorporates a simple, rule-based if X and Y then Z problem solving control approach. This approach relies upon an empirically based model, which is dependent on the design engineers control experience. The system is inherently robust as it does not require precise inputs, can be designed to fail safely if an input is lost, and despite the possible wide variation of the input signal, the output is always a smooth control signal. As the design engineer defines the rules that govern the system, the controller can easily be modified to improve or dramatically alter system performance. Finally, any sensor that presents the controller with an indication of the systems actions, regardless of sensor cost or precision, is a viable candidate for the fuzzy controller [13]. The fuzzy logic control model was applied to the four major intelligence functions of the control system: the stair protocol arbiter, the platform alignment controller, the auxiliary track controller, and the task used to realign the Andros upon the stairs after a slippage error has occurred. Each of these functions will be discussed as they are encountered in the descriptions of the control algorithms to follow. 3.2.2 Functionality To utilize the control capabilities of the Intelligent Primitive Driver, the command messages associated with the component must be completely defined to interact with the platform. The Set Auxiliary Actuators command must be mapped to control the platforms indirect motion actuators. Vehicle behaviors must be assigned a control number corresponding to one of the available Set Behavior commands, the requisite control data for the behavior must be defined and assigned to the proper command variable and the behavioral algorithms themselves must be characterized and coded for use.

PAGE 43

32 As shown in Table 3-2, the Set Auxiliary Actuators command message has eight assignable auxiliary actuators command fields. Following this convention, the front auxiliary track of the Andros robot is denoted as Aux Actuator 5 and the rear auxiliary track is denoted as Aux Actuator 6. These fields were chosen as the auxiliary tracks of the Andros may be moved to a specific angle through the use of the Auxiliary Track Position System, described in Chapter 2.3. The behavioral controls of the IPD are used to control the motion of the Andros on a set of stairs, both ascending and descending. The ascending motion behavior has been mapped to Set Behavior 1 with the descending motion mapped to Set Behavior 2. Both behaviors use the same the control data variables, which have been assigned to the data fields shown in Table 3-6. Table 3-6: Set Behavior 1 and 2 control data Field # Name Description 2 Behavioral Parameter 1 Rise of a Single Step (in.) 3 Behavioral Parameter 2 Run of a Single Step (in.) 4 Behavioral Parameter 3 Total Number of Steps 5 Behavioral Parameter 4 Not Used 6 Behavioral Parameter 5 Stair Heading (degrees) 7 Behavioral Parameter 6 Not Used 8 Behavioral Parameter 7 Not Used 9 Behavioral Parameter 8 Not Used 3.2.3 Program Logic Figure 3-2 depicts the logic flow diagram of the Intelligent Primitive Driver upon startup. This diagram is only representative of the Intelligent Primitive Driver and not the JAUS system on the whole. The receipt and execution of JAUS commands by standard components have been omitted because, for these instances, the controller

PAGE 44

33 behaves in a manner consistent with a standard JAUS controller. Upon startup of the Andros controller, the IPD enters a ready state and awaits the reception of an IPD command message. The receipt of one of these commands causes the IPD to assume control of the Andros and execute the desired commanded function. Start Controller Ready State CommandMsg Recvd?YesNo ExecuteCommand CommandCompleted? NoYes Figure 3-2: Intelligent Primitive Driver logic flow diagram Upon receipt of a Set Auxiliary Actuators command, the IPD moves into the algorithm as shown in Figure 3-3. The IPD uses the Auxiliary Track Positioning System, as outlined in Chapter 2.3, to determine the current angle of the auxiliary track. Once the current angle has been determined, the algorithm checks to see in which of three possible fuzzy sets the current track angle lies: less than the desired angle, greater than the desired angle, or around the desired angle. The IPD will determine the direction, if any, to rotate the track dependent upon which set the current track angle lies. If the current track angle

PAGE 45

34 is less than the desired track angle, the track is rotated counterclockwise. If the current track angle is greater than the desired track angle, the track is rotated clockwise. If the track angle is equal to the desired track angle, within an angular tolerance of +/-1 degree, the track is not rotated and the controller IPD returns to the ready state. The two-degree total tolerance was determined heuristically based upon the maximum update rate of the controller, the precision of the Auxiliary Track Positioning System and the overall speed of motion of the auxiliary tracks while rotating. This algorithm is followed independent of which auxiliary track is commanded to move. RecvCommand Read CurrentAux TrackAngle Current Angle Lessthen Desired Angle?Yes Rotate AuxTrack CCW Current AngleGreater then DesiredAngle?Yes Rotate AuxTrack CW Current Angle Equalto Desired Angle? Yes Task Complete NoNoNo Figure 3-3: Set Auxiliary Actuator algorithm

PAGE 46

35 Upon receipt of a Set Behavior command, the IPD executes the algorithm shown in Figure 3-4. The IPD calculates the total dimensions of the stairs from the control data received along with the command, as seen in Table 3-6. Through simple geometric equations, the IPD determines the total length, L, and pitch angle, of the stairs, as seen in Figure 3-5. Next, the IPD aligns the heading of the Andros platform with the heading of the staircase. Start Behavior Align Androswith Stairs AndrosAligned?YesNo Stair Length Lessthen Critical Length? BeginProtocol 1 BeginProtocol 2 Calculate StairDimensions Stair Length Greaterthen Critical Length? YesYesNo Start SkewAlignment Task Start StairCounter Task Figure 3-4: Opening sequence of Set Behavior X algorithm

PAGE 47

36 The align platform function is another of the fuzzy logic functions. It calculates the difference between the reported stair heading and the current heading of the Andros, obtained from the Andros onboard digital compass. The absolute value of the difference is then compared against the defined fuzzy sets. Figure 3-5: Stair data representation If the absolute value is greater than 90 degrees, the Andros is rotated at its maximum speed. If the absolute value is between 90 and 60 degrees of error, the Andros is rotated at 75% of its maximum speed. If the absolute value is between 60 and 25 degree of error, the Andros is rotated at 50% of its maximum speed. Finally, if the absolute value is less than 25 degrees, the Andros is rotated at 25% of its maximum speed. This function has an allowable angular tolerance of +/-4 degrees. The direction of the commanded rotation is also dependent upon a fuzzy interpretation of the angular difference. If the absolute value of the difference is less than 180 degrees and the actual difference is negative, the Andros is rotated counterclockwise at the desired speed. If the absolute value of the difference is less than 180 degrees and the actual difference is positive, the Andros is rotated clockwise at the desired speed. The direction of rotation relative to the actual Total Len g th Rise Total Run Total Rise Run

PAGE 48

37 value of the difference is reversed if the absolute value of the difference is found to be greater than 180 degrees. This ensures that the Andros takes the shortest route possible to reach the commanded heading. Once the Andros has been aligned, the IPD starts the skew alignment task. This is a separate program thread, which runs parallel to the main stair control thread. The purpose of the skew alignment task is to detect and counter any angular slippage of the Andros upon the staircase. Slip detection is accomplished by monitoring the difference between the current heading of the Andros and the heading of the stairs, similar to the align platform function. Figure 3-6: Skew alignment task correction Direction of Adjustment Direction of Slip If an angular slippage error is detected, the skew alignment task counters it by rotating the Andros in the direction opposite of the slippage. (Figure 3-6) This, again, is a fuzzy logic task as the slippage error is grouped into broad sets of possible angular error. If the error is greater than 5 degrees but less than 10, the Andros is rotated at 15%

PAGE 49

38 of its maximum speed. If the error is between 10 and 25 degrees, the Andros is rotated at 25% of its maximum speed. At greater than 25 degrees, the error begins to approach a non-recoverable state, and the Andros is stopped so that appropriate measures can be taken to safely move it off of the staircase. Once the heading error is less than the 6 degrees of angular tolerance, the Andros rotation is halted. The linear motion control command of the Andros is never affected by the skew alignment task, except for the case in which the error is greater than 25 degrees, as the Andros embedded controller allows for both linear and rotational motion components to be commanded at the same time. After the skew alignment task has been spawned, the IPD begins the stair counter task. The stair counter task uses the stair counter assembly, as described in chapter 2.3, to count the number of steps the Andros has successfully passed and also to account for any possible linear slippage error. The number of steps must be counted to provide the IPD with the relative position of the Andros upon the staircase to trigger stair motion events, such as auxiliary track motions. The next step for the IPD to complete is to determine which stair protocol should be evoked. This is accomplished by determining if the total length, L, of the staircase is less than or greater than the critical length. The critical length is defined as 1.5 times the total length of the Andros. If the total length is less than the critical length, protocol 1 is chosen. If the total length is greater than the critical length, protocol 2 is chosen. The reason for the demarcation between the two protocols is simple: a staircase with a total length equal to or less than the critical length simply does not have enough available length to adequately carry out the full range of stair climbing motions. Also, the majority of the stair motions are meant to ensure that the Andros is stable upon the staircase and

PAGE 50

39 that the tracks do not lose traction. This is not a concern on short staircases as it is on longer ones. It should be noted that the portion of the stair motion algorithm, as seen in Figure 3-4, is the same for both the ascend and the descend behavior commands. Also independent of the direction of travel upon the stairs is the protocol arbiter. Protocol 1 is designated for control of the Andros on a set of stairs less than the critical length in both the ascend and descend commands, protocol 2 corresponds to control of the Andros on a set of stairs longer than the critical length in both the ascend and descend commands. Once the stair protocol has been carried out, the controller reverts back to its ready state and awaits further commands from the System Commander. 3.2.4 Ascend Protocol 1 This stair motion protocol deals with the situation in which the total length of the staircase is less than the critical length. First, the front auxiliary tracks of the Andros are aligned with the angle of the stairs, (Figure 3-7a) Then, the Andros is simply started up the staircase. The protocol concludes as the Andros passes the last step of the staircase and is safely situated on the top landing, as seen in Figure 3-7c. 3.2.5 Ascend Protocol 2 The second ascend stair motion protocol deals with the situation where the total length of the staircase is longer than the critical length. In this situation, the full range of control steps are necessary to ensure that the Andros makes it safely to the top of the staircase. The first stage of the process is to align the front auxiliary tracks of the Andros with the angle of the stairs, and the rear auxiliary tracks parallel to the ground. (Figure 3-7a) This stage occurs while the Andros is preparing to climb the staircase, therefore

PAGE 51

40 there are no steps associated with it. In the next stage, the Andros is started up the staircase. After two steps have passed, the front auxiliary tracks are aligned parallel with the line of the stairs, as seen in Figure 3-7b. The Andros continues on in this third stage alignment until the last step of the staircase is reached. As this step is reached, the last stage is initiated. The front auxiliary tracks of the Andros are moved downward to catch the Andros as it passes the apex of the stairs. This can be seen in Figure 3-7c. Figure 3-7: Ascend stair motion protocol: a) Align front auxiliary tracks with stair angle; b) Andros moving on stairs; c) Andros moving over apex of stairs c) b) a)

PAGE 52

41 3.2.6 Descend Protocol 1 As with ascend protocol 1, descend protocol 1 is evoked when the total length of the staircase to be traversed is less than the critical length. The Andros is moved to the edge of the staircase and the front auxiliary tracks are moved downward to catch the Andros as it crosses the apex of the stairs, as seen in Figure 3-8a. Next, the Andros is simply driven over the edge of the steps and the front auxiliary tracks are moved parallel to the ground plane. Once the Andros has reached the floor level, it is moved away from the staircase. Figure 3-8: Descend stair motion protocol: a) front auxiliary track moved to catch Andros; b) rear auxiliary track moved to push Andros over apex; c) align front auxiliary track with stairs; d) front auxiliary tracks moved to catch Andros at stair landing a) b) c) d)

PAGE 53

42 3.2.7 Descend Protocol 2 Descend protocol 2 occurs when the total length of the staircase to be traversed down is longer than the critical length. The Andros is moved to the edge of the stairs and the front auxiliary tracks are moved downward to catch the Andros as it crosses the apex of the stairs. (Figure 3-8a) While this is occurring, the rear auxiliary tracks are moved downward to help rotate the Andros down to the plane of the staircase. (Figure 3-8b) The Andros is moved forward until the main tracks come in contact with the stairs, as seen in Figure 3-8c. The controller uses the end of world capability of the stair counter assembly to determine the edge of the stairs, as discussed in Chapter 2.3. The Andros is moved further forward and rear auxiliary tracks are moved to a horizontal position. The Andros is moved down the steps until the third to last step is reached. Then, the front auxiliary tracks are moved to parallel to the ground plane, which allows the Andros to make an easy transition to the plane of the floor. (Figure 3-8d) The Andros is then moved off and away from the staircase.

PAGE 54

CHAPTER 4 TESTING AND RESULTS This chapter describes the testing of the individual subsystems associated with the Andros Intelligent Primitive Driver (IPD). Testing procedures and results will be reported for the stair-counter assembly, the auxiliary track positioning system and the heading alignment controller. 4.1 Stair-Counter Assembly 4.1.1 Testing Procedure The stair counter assembly was tested to ascertain whether or not the concept would accurately count the number of stairs the platform has passed and therefore, be a viable addition to the positioning system. The first step to accomplish this task was to calibrate the infrared sensors that the system uses. This was done to correlate the values returned from the analog-to-digital converter (ADC), which are used to interface the Sharp GP2D12 infrared object detectors and the Rabbit RCM3200 microcontroller, to their corresponding distances. To do this, a target was first placed a known distance away from the infrared sensor. Then, one hundred readings of the value returned from the infrared sensor through the ADC were recorded and their average obtained. The target was then moved to another known distance and the average value was again found. This process was repeated for distances measuring 4, 6, 8, 10, 12, 14 inches. The data points were plotted using Excel and several regression curves were applied to determine which type best fit the data. It was determined that the non-linear power function shown in 43

PAGE 55

44 Figure 4-1 best described the output. The equation shown was then used in the code to convert the ADC readings to distances for the testing. y = 496.6x-0.9R2 = 0.9974020406080100120140160024681012141Distance (in)ADC Value 6 Figure 4-1: Calibration data for Sharp GP2D12 infrared object detectors Once the infrared sensor had been calibrated, a method of gathering the test data from the staircase needed to be devised. To accomplish this, a testing frame made from 80/20 extruded aluminum framing system was constructed. The 80/20 was chosen for this task as it was easily assembled and the extruded grooves were ideal for constraining the motion of the test sled along the major axis of the stairs. The test sled housed the Rabbit microcontroller as well as one of the Sharp GP2D12 infrared object detectors to acquire the range data. The sled was then tethered to a 12-volt gear motor to pull it along at a

PAGE 56

45 relatively constant velocity. The entire assembly was placed upon the stairs, as seen in Figure 4-2. Figure 4-2: Stair-counter testing assembly The system recorded a reading of the range data from the surface of the staircase to the infrared sensor once every 50 milliseconds. This delay was chosen, as it is longer than the 32-millisecond update rate of the infrared sensors and therefore ensured that no duplicate readings were accidentally recorded by the system. The microcontroller then determined the first derivative of the data, applied a three element median filter to it, and then determined the second derivative. A Dell Inspiron 8100 laptop computer then recorded this data set. Communication between the Dell and the Rabbit were made via the 57.6-kBaud connection provided for diagnostic purposes by the microcontroller. The test was run a total of ten times on two separate staircases. The stair-counter testing also had a secondary purpose: to empirically determine a second derivative threshold value for the stair-counter control code. The stair-counter

PAGE 57

46 code uses the second derivative values to determine if a stair has been passed and should therefore be counted. However, detecting a single second derivative value for this purpose is futile; a range of second derivative values that correspond to a stair edge may be encountered. The system may also experience subtle negative second derivative peaks due to uneven motion of the Andros upon the stairs. To account for all of this, the second derivative value is compared to a threshold value. If the value is less than the threshold, it is determined to be a stair edge and is counted. 4.1.2 Results The data collected from the stair-counter testing rig was placed into an Excel spreadsheet for graphing purposes. The data was analyzed to determine when the second derivative of the stair representation occurred with respect to the recorded inflection point, or outside edge, of the stairs. Figure 4-3a illustrates the first set of sample data from the acquired from the testing. The dark blue line represents the detected outline of the staircase, while the red line represents the calculated second derivative of this data. Clearly visible are the two large negative impulses, each one corresponding to one of the stair peaks shown. As designed, each impulse is logged 0.25 seconds after the stair peak is experienced. The same is true of Figures 4-3b and 4-3c; each one has two large, negative impulses that occur 0.25 seconds after their corresponding stair peaks are detected. Also, in each of these figures, the negative impulses are less than .2, while none of the tertiary negative impulses approach this value. Therefore, this was determined to be the optimum threshold value for the system to use.

PAGE 58

47 b) Stair Data Representation and 2nd Derivative Data, Sample 2012345678910012345678910111213141516Time (sec)Distance (in)-1-0.8-0.6-0.4-0.200.20.40.60.81 Stair Data 2nd Derivative a) Stair Data Representation and 2nd Derivative Data, Sample101234567891001234567891011121314151617Time (Sec)Distance (In)-1-0.8-0.6-0.4-0.200.20.40.60.81 Stair Data 2nd Derivative c) Stair Data Representation and 2nd Derivative Data, Sample 30123456789100123456789101112131415Time (sec)Distance (in)-1-0.8-0.6-0.4-0.200.20.40.60.81 Stair Data 2nd Derivative Figure 4-3: Stair-counter data: a) sample 1, b) sample 2, c) sample 3

PAGE 59

48 4.2 Auxiliary Track Positioning System 4.2.1 Testing Procedure The setup for the auxiliary track positioning system testing had two steps. First, the maximum and minimum values returned to the system by the Draw Wire Transducer (DWT) were obtained. These values are used in conjunction with Equation 2-1 to convert the measured DWT value to an angular measurement. The maximum value occurs when the auxiliary track has been rotated to its topmost point, while the minimum value occurs when the auxiliary track has been rotated to its bottommost point; these points correspond to 150 degrees and 0 degrees, respectively. At each of these two points, one hundred values of the DWT were taken and then an average value was obtained. Figure 4-4: Plumb compass attached to Andros auxiliary track

PAGE 60

49 The second step in the setup was to affix a plumb compass to the auxiliary track so that an independent angle measurement of the position of the track could be made. A plumb compass is comprised of a needle, weighted at the bottom, along with an adjustable faceplate. By attaching the body of the plumb compass to a structure, the relative angle of the structure with respect to ground may be found when the structure is rotated. The Andros auxiliary tracks were rotated to their bottommost point and the adjustable face of the plumb compass was then adjusted such that the compass needle pointed to 0 degrees. In this configuration, the compass needle pointed to 150 degrees when the auxiliary tracks were rotated to their topmost position, which corresponds to the measurement convention utilized by the controller. Figure 4-4 illustrates the plumb compass attached to the Andros auxiliary track. To test the commands for the auxiliary track positioning system, the Operator Control Unit (OCU) was used to send the experimental JAUS message, Set Auxiliary Actuators, to the Andros JAUS controller, along with a commanded angular position of the auxiliary track. The initial set of commanded angles were used to determine the minimum allowable tolerance that could be used by the system without the system becoming unstable. In this case, the system would be unstable if the controller continually reversed the direction of the auxiliary track in an attempt to move the track to the desired angle and be within the given tolerance. The minimum allowable tolerance for the system was found to be +/1 degree. Following this, another set of Set Auxiliary Actuators commands were sent to the system and the commanded angle, the angle returned by the DWT sensor, and the angle read off of the plumb compass were recorded.

PAGE 61

50 4.2.2 Results Figure 4-5 shows a plot of the controller commanded halt angle and the actuator halt angle versus the commanded angle sent to the controller from the OCU. The controller commanded halt angle is the angle returned to the controller from the DWT sensor at the instant that the controller issued the halt rotation command. The actuator halt angle is the angle read from the plumb compass and corresponds to the angle of the auxiliary track after the rotation has actually stopped. Both sets of data points have a linear distribution across the entirety of the available range of motion, as illustrated by the applied trend lines and their respective R 2 values. The controller commanded halt angle and the actuator halt angle are identical at 0 degrees and 150 degrees because there are physical stops at these points of rotation on the Andros frame. y = 1.0.x 1.6R2 = 0.9921y = 1.0x + 0.4R2 = 0.999801020304050607080901001101201301401500102030405060708090100110120130140150Commanded Angle (Degrees)Angle (Degrees) Actuator Halt Angle Controller Commanded Halt Angle Actuator Halt Angle Controller Commanded Halt Angle Figure 4-5: Controller commanded halt angle and actuator halt angle versus operator commanded angle

PAGE 62

51 Figure 4-6 depicts a plot of the error between the commanded angle sent from the OCU and the controller commanded halt error and the actuator halt angle. The controller commanded halt error is the error between the commanded angle and the auxiliary track angle at the instant that the controller issued the halt command and is recorded from the DWT sensor. The actuator halt error is the error between the commanded angle and the auxiliary track angle after the track actually stops and is recorded from the plumb compass. The average error value returned from the DWT sensor is 0.5 degrees with a standard deviation of 0.3, whereas the average error value returned from the plumb compass is 3.4 degrees with a standard deviation of 2.2. Figure 4-6: Controller commanded halt error and actuator halt error versus operator commanded angle -9.0-8.0-7.0-6.0-5.0-4.0-3.0-2.0-1.00.01.02.03.04.05.06.07.08.0 9 0 0102030405060708090100110120130140150Commanded An g le ( De g rees ) Error (Degrees) Controller Commanded Halt Angle Error Actuator Halt Angle Error

PAGE 63

52 4.3 Heading Alignment Controller 4.3.1 Testing Procedure The first step necessary to test the heading alignment controller was to calibrate the PNI Corporation TCM2-20 digital compass. A serial connection was established between the digital compass and a Dell Inspiron 8100 laptop computer and the digital compass was placed into polling mode. Then, the compass was given the command to start its calibration cycle and the Andros was slowly rotated in a circle for approximately four minutes. Once this was completed, a series of Set Behavior 1 commands were sent from the OCU to the Andros JAUS controller, along with the desired heading. The JAUS controller was coded such that the Set Behavior 1 command initiated the heading alignment code. The first series of tests were administered to determine the minimum allowable tolerance value that the system could accept without the system becoming unstable. In this situation, the system would be unstable if the controller continually reversed the rotation of the Andros in an attempt to move the Andros to the desired heading. From these initial tests, the allowable tolerance for the system was found to be +/4 degrees. After this was completed, another set of Set Behavior 1 commands were sent from the OCU and the commanded heading, compass heading, and final Andros heading were recorded. The compass heading is the value that the digital compass last reported to the controller to illicit a stop rotation command. The final Andros heading is the compass measure of the heading of the Andros when the rotation actually stops. 4.3.2 Results Figure 4-7 depicts a plot of the controller commanded halt heading and the vehicle halt heading versus the desired heading sent from the OCU. The controller commanded halt heading is the heading returned to the controller at the instant that the controller

PAGE 64

53 issues a stop vehicle rotation command. The vehicle halt heading is the heading of the vehicle when the vehicle actually stopped its rotation. Both sets of data have a linear distribution across the entire range of rotation, as illustrated by the applied trend lines and their respective R 2 values. y = 1.0x 3.2R2 = 0.9967y = 0.9x + 2.2R2 = 0.9992020406080100120140160180200220240260280300320340360020406080100120140160180200220240260280300320340360Desired Heading (Degrees)Heading (Degrees) Vehicle Halt Heading Controller Commanded Heading Vehicle Halt Heading Controller Commanded Heading Figure 4-7: Controller commanded halt heading and vehicle halt heading versus operator commanded heading Figure 4-8 depicts a plot of the controller commanded heading error and the vehicle heading error versus the desired heading sent from the OCU. The controller commanded heading error is the error between the desired heading and the heading of the vehicle when the controller issues a stop rotation command. The vehicle heading error is the error between the desired heading and the heading of the vehicle when its rotation is actually stopped. The average error value for the controller heading is 2.8 degrees with a

PAGE 65

54 standard deviation of 0.8, whereas the average error value for the final Andros heading is 5.9 degrees with a standard deviation of 1.7. -10-9-8-7-6-5-4-3-2-1012345678910060120180240300360Heading (Degrees)Error (Degrees) Vehicle Heading Error Controller Commanded Heading Error Figure 4-8: Controller commanded heading error and vehicle heading error versus operator commanded heading

PAGE 66

CHAPTER 5 CONCLUSIONS AND FUTURE WORK 5.1 Conclusions This research focused on the development of the Intelligent Primitive Driver (IPD), an experimental, low-level, intelligence component for the Joint Architecture for Unmanned Systems (JAUS). Three objectives were necessary to accomplish this task. First, the IPD had to meet the criteria of a fully defined, standard JAUS component. Second, a testing platform had to made JAUS compliant and the functionality of the IPD had to be applied to the testing platform. Finally, the intelligence components of the IPD that were applied to the testing platform had to be tested. A standard JAUS component is defined through four criteria: the function of the component, the accepted input and output messages that the component may handle, and the full description of the component. In these terms, the IPD was fully constrained to the JAUS architecture. The purpose was defined as being responsible for the control of all indirect motion related actuators. A full set of input and output messages were defined to meet the JAUS message standards. The component description defined the implementation of the IPD into the JAUS architecture, set the IPDs unique component identification number at 99, and discussed the specifics of the IPDs functionality. A Remotec Andros robot was chosen as the testing platform because of the indirect motion actuators located on the chassis and its complicated behavioral controls, namely stair-climbing. A complete JAUS controller was developed specifically to be used by the 55

PAGE 67

56 Andros platform; an Operator Control Unit (OCU), Primitive Driver, Node Manager, Position System and Communicator components were coded for both the Rabbit RCM3200 microcontroller with the Dynamic C operating system and the Gateway Solo 3350 laptop with the Linux Redhat 8.0 operating system. The Rabbit was used as the Andros JAUS controller, while the Solo 3350 was used as the OCU. The Intelligent Primitive Driver was applied to the Andros platform: the IPDs capability to control indirect motion actuators were mapped to the auxiliary tracks of the Andros and the behavioral control commands were mapped to the stair ascending and descending procedures. The proprietary Andros control stream was reverse engineered from the native Andros controller and then applied to the Primitive Driver and Intelligent Primitive Driver. As such, the Andros JAUS controller was able to accept and interpret JAUS commands and incite the Andros to act upon these commands accordingly. The controller, as mounted on the Andros platform, can be seen in Figure 5-1. Figure 5-1: Controller mounted on Andros platform

PAGE 68

57 The intelligence components of the Intelligent Primitive Driver were tested to ensure that they adequately performed the desired control function. A testing frame was constructed to constrain the motion of a sled housing one of the Sharp GP2D12 infrared object detectors so that the stair-counter assembly could be tested. From the data gathered from the system, it was shown that the negative second derivative impulses could be observed by the system and that they did indeed lag the detection of the outside stair edge by 0.25 seconds, as designed. The auxiliary track positioning system was tested to determine if the final angular placement of the auxiliary tracks coincided with the desired angular command. It was found that the average error value for the controller commanded halt angle was 0.5 degrees with a standard deviation of 0.3, whereas the average error value for the actual auxiliary actuator position was 3.4 degrees with a standard deviation of 2.2. The minimum allowable tolerance for this control system was +/1 degree. The heading alignment controller was tested to determine if the final heading of the Andros coincided with the desired heading command. It was found that the average error value for the controller commanded halt heading was 2.8 degrees with a standard deviation of 0.8, whereas the average error value for the actual halt heading of the Andros was 5.9 degrees with a standard deviation of 1.7. The minimum allowable tolerance for this control system was +/4 degrees. Both of these control systems performed as designed and returned favorable data when the limitations inherent to the Andros platform were taken into account. The discrepancies between the DWT and plumb compass error in the auxiliary track positioning system and the final heading and compass heading error in the heading alignment controller are a direct manifestation of the limitations of the Andros system.

PAGE 69

58 As discussed in Chapter 2, the maximum update rate of the Andros control stream is 5 Hz. In terms of autonomous computer controllers, 0.2 seconds is a relatively long amount of time. In both the auxiliary track positioning system and the heading alignment controller tests, the controller commanded a halt of system motion that was not acted upon until at least 0.2 seconds later. This fact translated into an average difference of 2.9 degrees for the auxiliary track positioning system and an average difference of 3.1 degrees for the heading alignment controller. Therefore, when the controller believes it has reached the desired command position and has thus stopped the motion of the Andros, the Andros is in actuality continuing to move. It is for this reason that the Andros stair motion behavior has been broken down into its component parts and these parts have been tested individually, instead of simply testing the Andros stair motion controller in its entirety; it is entirely within the realm of possibility that the Andros would incur a non-recoverable, fatal error when attempting to negotiate a staircase even though the controller recognized the error and attempted to correct it. The Andros is able to negotiate a set of stairs when controlled by a human operator with a more reasonable expectation of a successful conclusion than with the JAUS controller for two reasons, though it is still a very difficult and complicated task. First, in terms of human control, 0.2 seconds is a relatively long amount of time. Second, the human operator has both control experience and predicate knowledge of the system. Therefore, the human operator can make predictive assumptions concerning the stair motion process that the JAUS controller is unable to make. For example, the human operator can take into account the type of stair to be traveled upon, the condition of the Andros tracks, and the amount of traction that the Andros is exhibiting when actually on

PAGE 70

59 the stairs to make corrections to the stair motion process. With this incarnation of the IPD, these predictive capabilities are not present. 5.2 Future Work To increase the controllability of the Andros-IPD system, upgrades need to be made to several of the subsystems. First, and most importantly, the Andros embedded controller should be updated to a more modern control scheme. The outdated controller and its 1200-Baud connection should be replaced by a modern microcontroller utilizing a secure Ethernet connection protocol, such as the Transmission Control Protocol (TCP). This replacement would solve the control problems, which currently inhibit the system. When making this update, the current drive motors and auxiliary track positioning motors should be replaced with motors that have integrated rotary encoders. This would serve two purposes. First, the encoders located on the driver motors could be utilized to add dead-reckoning capability to the current position system. With this, specific information concerning the total movement of each individual track could be collected and used for more exact vehicle placement. Second, the encoders on the auxiliary track positioning motors could replace the Draw Wire Transducers (DWT) currently used to acquire auxiliary track position. The DWT sensors work very well, but are susceptible to environmental conditions and hazards; the internal encoders would not have this potential problem. The Intelligent Primitive Driver should be modified to include adaptive control capabilities to the stair motion algorithms. Concepts of neural networks could be applied to the controller to give it the ability to learn from stair motion trials. This would allow the system to adapt the stair motion algorithms to work more efficiently on different types of stairs. For example, the controller could determine if an auxiliary track should

PAGE 71

60 be moved at a different point during the stair motion algorithm or change the correction speeds used to correct the Andros if it slips on the staircase. Finally, the Intelligent Primitive Driver should be applied to other JAUS compliant platforms and further application testing should be performed. In doing this, the viability of the component could be completely explored and documented. After this, the component could be presented to the Working Group of the Joint Architecture for Autonomous Systems (JAUS) for the formal inclusion of the IPD into the Reference Architecture.

PAGE 72

APPENDIX A STANDARD JAUS MESSAGES This Appendix contains information pertaining to the Set Wrench Effort and Query Global Pose standard JAUS messages, as well as a list of the core JAUS message set. A.1 Query Global Pose The command code for this message is defined as 0x2402 and causes the receiving component to respond with a Report Global Pose message. Table A-1 depicts the data field assignments for the Query Global Pose message [10]. Table A-1: Query Global Pose data field (used from JAUS: Reference Architecture Specification, pg. 93) Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Report Global Pose Message A.2 Set Wrench Effort The command code for this message is defined as 0x0405 and controls platform mobility actuators by mapping the six propulsive and six resistive elements that comprise a wrench command to the mobility actuators of a vehicle. Table A-2 depicts the data field assignments for the Set Wrench Effort message [10]. 61

PAGE 73

62 Table A-2: Set Wrench Effort data fields (from JAUS: Reference Architecture Specification, pg. 80) Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See mapping table that follows. 2 Propulsive Linear Effort X 3 Propulsive Linear Effort Y 4 Propulsive Linear Effort Z 5 Propulsive Rotational Effort X 6 Propulsive Rotational Effort Y 7 Propulsive Rotational Effort Z Short Integer Percent Scaled Integer Lower Limit = -100 Upper Limit = 100 8 Resistive Linear Effort X 9 Resistive Linear Effort Y 10 Resistive Linear Effort Z 11 Resistive Rotational Effort X 12 Resistive Rotational Effort Y 13 Resistive Rotational Effort Z Byte Percent Scaled Integer Lower Limit = 0 Upper Limit = 100 Vector to Data Field Mapping for Above Command Vector Bit 15 14 13 12 11 10 9 8 Data Field R R R R 13 12 11 10 Vector Bit 7 6 5 4 3 2 1 0 Data Field 9 8 7 6 5 4 3 2 R indicates that the bit is reserved.

PAGE 74

63 A.3 JAUS Core Message Set Table A-3 shows the core set of JAUS messages and their corresponding command codes [10]. Table A-3: JAUS core message set Code Description 0x01 Set Component Authority 0x02 Shutdown 0x03 Standby 0x04 Resume 0x05 Reset 0x06 Set Emergency 0x07 Clear Emergency 0x08 Create Service Connection 0x09 Confirm Service Connection 0x0A Activate Service Connection 0x0B Suspend Service Connection 0x0C Terminate Service Connection 0x0D Request Component Control 0x0E Release Component Control 0x0F Confirm Component Control 0x10 Reject Component Control

PAGE 75

APPENDIX B STAIR COUNTER MATHEMATICAL DEVELOPMENT The ability to count the number of steps the Andros has passed is critical to the ability of the Intelligent Primitive Driver to perform its designed task. As discussed in Chapter 3, the current location on the stairs of the Andros is used to trigger controlled events during the stair climbing procedure. To ensure that this was done as accurately as possible, the optimum deployment angle for the infrared sensors needed to be determined so that the stair peaks and their corresponding second derivative impulses were easily observable by the system. Figure B-1: Stair representation 64 offset run rise YXSensor Line of Action

PAGE 76

65 The stair representation used for this development has been drawn relative to the plane of motion of the Andros, as shown in Figure B-1. This reference frame is appropriate as the sensor array moves along a path parallel to the plane of motion of the Andros and the measured distances are relative to this plane, and not to the ground plane. The single stair representation shown is defined by its rise, run, and the angle, which is determined through basic geometry and is constructed of two lines that are perpendicular to each other at their single point of intersection. As the stair representation is constructed of two linear equations, one for the rise and one for the run, two separate equations for the distance, d, must be developed. The distance, d, is the range distance measured from the infrared sensor to the profile of the stair. Figure B-2: Stair runner model a f d (xo,yo)(x,y)Y X Stair Runner

PAGE 77

66 Figure B-2 shows the model used for the development of the equation for the distance, d, as it applies to runner of the stair. The first step in determining d is to find the point of intersection between the stair runner linear equation and the line of action of the sensor, (x 0 y 0 ). As the y-axis component of this point is constrained to be at y 0 x 0 can easily be found by solving the equation of the line. Using this as the point of origin, the distance, a, can be found to the point (x,y), which corresponds to the current location of the sensor. This distance is given as: 2020yyxxa (B-1) Now that the distance, a, has been acquired, the perpendicular distance, f, can be found by the equation: sinaf (B-2) Through the similar triangles concept, the angle, is shown on the two locations of Figure B-2. The angle, is the user-defined angle of the infrared sensor. Therefore, the intermediate angle, may be found, which then leads to the angle, by the equation: 90 (B-3) The distance, d, is now simply: cosfd (B-4) Figure B-3 shows the model used for the development of the equation for the distance, d, as it applies to riser of the stair. Again, the first step is to find the point of intersection, (x 0 y 0 ), between the stair riser linear equation and the line of action of the sensor. Again, as the y-axis value is constrained to be y 0 x 0 can be found by solving the

PAGE 78

67 equation of the line. Using this as the point of origin, the distance, a, can be found to the point (x,y), which corresponds to the current location of the sensor. Figure B-3: Stair riser model The equation for this distance is shown in Equation B-1. Through the similar triangles concept, the angle, is shown on the two locations of Figure B-3. The angle, is the user-defined angle of the infrared sensor. Using and the angle, may now be found by: (B-5) a d f (xo,yo)(x,y) Stair Riser X The distance, f, is defined as: cosaf (B-6) Finally, the distance, d, may be found by: cosfd (B-7)

PAGE 79

68 The two equations for the distance, d, and the stair data representation were placed into an Excel spreadsheet for analysis. From this, Figure B-4 was obtained. As shown in the figure, if the user-defined sensor angle, is less than 90 degrees relative to the line of action of the sensors, the stair edge is skewed to the left and the risers are more pronounced over the range of the stair data. If is greater than 90 degrees to the line of action of the sensors, the stair edge is skewed to the right and the runners are more pronounced over the range of the stair data. Therefore, it was determined that should be 90 degrees, or perpendicular to the line of action of the sensors, as this case is neutral and shows no preference to either the risers or to the runners of the stair data. As the stair edges are more pronounced in the neutral case, so to will the second derivative impulses be more pronounced and more easily observed by the system. 024681012141618012345678910111213141516Distance (in)Distance (in) Figure B-4: Calculated distances, d, for varying value of

PAGE 80

LIST OF REFERENCES [1] Bayouth, M., Nourbakhsh, I., and Thorpe, C., "A Hybrid Human-Computer Autonomous Vehicle Architecture," Third ECPD International Conference on Advanced Robotics, Intelligent Automation and Control, 1997. [2] Mustererkennung und Szenenanalyse (MESA) Research Group, 2003, Semi-Autonomous Driving: Intelligent Cruise Control, MESA Research Group, http://www.neuroinformatik.ruhrunibochum.de/PROJECTS/PATREC/projects/DAS/sadicc/sadicc_d.html Feb 2003. [3] Schlegel, N.,1997, Autonomous Vehicle Control Using Image Processing, Virginia Polytechnic Institute and State University, http://scholar.lib.vt.edu/theses/public/ etd-283421290973280/etd.pdf Feb 2003. [4] Connell, J. and Viola, P., Cooperative Control of a Semi-Autonomous Mobile Robot, Proc. of the 1990 IEEE International Conf. on Robotics and Automation (ICRA-90), 1990, pp. 1118-1121. [5] Huntsberger, T., and Rose, J., "Behavior-based control for autonomous mobile robots," ROBOTICS2000, Albuquerque, NM, Mar 2000, pp. 299-305. [6] Matthies, L., Xiong, Y., Hogg, R., Zhu, D., Rankin, A., Kennedy, B., Hebert, M., Maclachlan, R., Won, C., Frost, T., Sukhatme, G., McHenry, M., and Goldberg, S., A Portable, Autonomous, Urban Reconnaissance Robot, The 6th International Conference on Intelligent Autonomous Systems, Venice, Italy, July 2000. [7] Lewis, M., and Simo, L.Certain Principles of Biomorphic Robots, Autonomous Robots, volume 11, 2001, pp. 221-226. [8] Talebi, S., M. Buehler, M., and Papadopoulos, E., "Towards Dynamic Step Climbing for a Quadruped Robot with Compliant Legs," Proceedings of the 3rd International Conference on Climbing and Walking Robots, Madrid, Spain, October 2000. [9] Lauria, M., Piguet, Y. and Siegwart, R. Octopus An Autonomous Wheeled Climbing Robot, In Proceedings of the Fifth International Conference on Climbing and Walking Robots. Published by Professional Engineering Publishing Limited, Bury St Edmunds and London, UK, 2002. 69

PAGE 81

70 [10] JAUS Working Group, 2002, Joint Architecture for Unmanned Systems (JAUS): Reference Architecture Specification, Version 3.0, Volume 2, The Joint Architecture for Unmanned Systems, http://www.jaugs.org Feb 2003. [11] Operations and Maintenance Manual for Andros Mark VI Robot System, Remotec, Inc., Oak Ridge, TN., (2001). [12] Bock, R., 1998, The Data Analysis BriefBook: Median Filter, Forschungszentrum Juelich, http://ikpe1101.ikp.kfajuelich.de/briefbook_data_analysis/node168.html June 2003. [13] Tanaka, K., An Introduction to Fuzzy Logic for Practical Applications, Springer, New York, New York, (1997).

PAGE 82

BIOGRAPHICAL SKETCH Peter M. Vinch, Jr. was born on October 29, 1976 in Lawrenceville, New Jersey to Peter and Nancy Vinch, Sr. He received his Bachelor of Science degree in mechanical engineering, graduating with honors, from the Rochester Institute of Technology in May of 2000. In August of 2000, he enrolled at the University of Florida and entered the masters program in the Department of Mechanical and Aerospace Engineering. Upon graduation from the University of Florida, he plans to work in the area of autonomous vehicle development. 71

PAGE 83

University of Florida Graduate School Electronic Thesis and Dissertation (ETD) Rights and Permission 1. Enter and submit on line. 2. Print, sign, and submit to Graduate School Editorial Office Student Name: ____________________________________________________________ ID#: ____________________________________________________________ Document Type: ________Masters Thesis ________Doctoral Dissertation Document Title: Student Agreement: I hereby certify that I have obtained all necessary permission in writing for copyrighted material to be published in my thesis or dissertation. Further, I certify that I have obtained and attached hereto a written permission statement from the owner(s) of any copyrighted matter to be included in my thesis or dissertation, allowing distribution as specified below. Copies of all such permissions are maintained in my files. I hereby grant to the University of Florida and its employees the nonexclusive license to archive and make accessible, under the conditions specified below, my thesis or dissertation in whole or in part in all forms of media, now or hereafter known. This is a license rather than assignments, and I, therefore, retain all other ownership rights to the copyright of the thesis or dissertation. I also retain the right to use in future works (such as articles or books) all or part of this thesis or dissertation. In addition to the unrestricted display of the bibliographic information and the abstract, I agree that the above mentioned document be placed in the ETD archive with the following status (choose one of 1, 2, or 3) by checking the appropriate space below): ___ 1. Release the entire work immediately for access worldwide. ___ 2. Restrict access to the entire work to the University of Florida and all patrons of its libraries, including interlibrary sharing and release of doctoral dissertations to UMI. [Please check appropriate time span.] After (__1, __2, __3, __4, __5, __10) years release my work worldwide unless you receive in writing a request from me to continue restricted access. If I choose to release the work for worldwide access sooner, I will contact Library Archives, P.O. Box 117007, University of Florida, Gainesville, FL 32611. ___ 3. Secure the entire work for patent and/or proprietary purposes for a period of six months. During this period the copyright owner also agrees not to exercise her/his ownership rights, including public use in works, without prior authorization from the University of Florida. At the end of the six-month period, either I or the University of Florida may request an extension for an additional six months. At the end of the six-month secure period (or its extension, if such is requested), the work will be handled under option 1 above, unless I request option 2 in writing. The undersigned agrees to abide by the statements above, and agrees that this approval form updates any and all previous approval forms submitted heretofore. Signed: ______________________________________ ___________________ (Student) (Date) ______________________________________ ___________________ (Chair) (Date)

PAGE 84

University of Florida Graduate School Electronic Thesis and Dissertation (ETD) Signature Page Student's Name: ____________________________________________________________ This document has been reviewed and accepted by the student's supervisory committee. Professors name & title including department Professors signature ____________________________Chair ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ Month and Year of Graduation: ____________________________________ College Dean: ____________________________________ (when required by college) Graduate Dean: ____________________________________


Permanent Link: http://ufdc.ufl.edu/UFE0001146/00001

Material Information

Title: Design and implementation of an intelligent primitive driver
Physical Description: Mixed Material
Creator: Vinch, Peter M. ( Author, Primary )
Publication Date: 2003
Copyright Date: 2003

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0001146:00001

Permanent Link: http://ufdc.ufl.edu/UFE0001146/00001

Material Information

Title: Design and implementation of an intelligent primitive driver
Physical Description: Mixed Material
Creator: Vinch, Peter M. ( Author, Primary )
Publication Date: 2003
Copyright Date: 2003

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0001146:00001


This item has the following downloads:


Full Text











DESIGN AND IMPLEMENTATION OF AN INTELLIGENT PRIMITIVE DRIVER


By

PETER M. VINCH, JR.


















A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2003




























Copyright 2003

by

Peter M. Vinch, Jr.





























"What we call the beginning is often the end. And to make an end is to make a beginning.
The end is where we start from."
T.S. Eliot, "Four Quartets"















ACKNOWLEDGMENTS

There are many individuals, on professional and personal fronts, whom I would like to

thank for making possible the preparation and completion of this thesis. Professionally, I

would like to thank Dr. Carl D. Crane, III (my academic advisor and chair of my graduate

committee) for his direction, advice and encouragement. I also greatly appreciate the time

and energy that the other members of my supervisory committee (Dr. John K. Schueller

and Dr. Eric M. Scwartz) dedicated to my cause. I would like to extend my gratitude to

the Nuclear and Radiological Engineering Department of the University of Florida for

allowing me the use of their Remotec Andros robot for testing purposes. I thank the U.S.

Department of Energy (Grant #DE-FG04-86NE37967) and the Air Force Research

Laboratory located at Tyndall Air Force Base, Florida (contract # F08637-00-C6008) for

all of their support. I am also grateful to the entire staff of the Center for Intelligent

Machines and Robotics, for all of their assistance with the completion of my thesis.

Additionally, I would like to distinguish the contributions of Shannon Ridgeway, Daniel

Kent, Carl P. Evans, III, and especially Dr. David Keith Novick for all of their

professional advice and the friendship that they have extended to me. Without these

individuals, none of this would have been possible.

Personally, I would like to thank all of my friends and family for their efforts to keep

me sane and functional. Key people in this effort were Andrew and Gretchen McGraw,

whose friendship, support and love I will always value. I would also like to thank Adam

Feinberg for being such a great roommate, lifting partner, and best friend. He has pushed









me to become better in every aspect of my life; and for this I will always be grateful. Of

course, without the love and support of my family, all of my efforts would be fruitless.

Therefore, I would like to thank my mother, Nancy; my two sisters, Bridget and Melissa;

and my grandfather, Philip. Finally, I would like to thank my father, Peter M. Vinch, Sr.;

and my uncle, Robert Frie. These men have been my greatest influences, helping to place

me on the proper path through life. Without them, I would have been lost.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ......... ............... ................................................................... iv

LIST OF TABLES ........................... ...... ........ ................... viii

LIST OF FIGURES ......... ......................... ...... ........ ............ ix

ABSTRACT ........ .............. ............. ...... ...................... xi

CHAPTERS

1 INTRODUCTION AND BACKGROUND ...................................... ................

1 .1 In tro d u ctio n ............. .. ............. ........................................................................... 1
1.2 Background ............. .............. ............. 1
1.2.1 A assisted Teleop Control .......................... ...... .. ................................ 1
1.2.2 Stair Clim bing ........................................ 3
1.3 The Joint Architecture for Unmanned Systems (JAUS)................ .................... 4
1.3 .1 O v erv iew ................................................................ ............................. . 4
1.3.2 System Topology.............................. .............. 6
1.3.3 The JA U S C om ponent.............................................. ........................... 7
1.3 .4 T h e JA U S M essag e ......................................................................................... 7

2 TEST PLATFORM DEVELOPMENT .............. ...................... .............. 10

2.1 R em otec A ndros R obot..................... ...................................... .......................... 10
2.2 A ndros JA U S C ontroller................................................... .......................... 12
2.3 Sensor System s ........................................................ ......... 15
2 .3.1 Stair C ounter A ssem bly ....................................................... ... ................. 15
2.3.2 Auxiliary Track Positioning System ..................................................... 20
2.3.3 JA U S Positioning System ........................................ .................. ...... 21
2.4 O operator C control U nit ........................................................... ... .............. 22

3 INTELLIGENT PRIMITIVE DRIVER DEFINITION AND APPLICATION............24

3 .1 C om p on ent D definition ............................................................................................ 24
3.1.1 Com ponent Function ..................................................... .................. 24
3.1.2 Com ponent I/O ................................................... ... .. ........ .. 24
3.1.3 C om ponent D description ....................................................... ... ................. 25









3.1.4 IPD Input and Output M messages ........... ................................... 27
3.1.4.1 "Set Auxiliary Actuators" ............. ..... .... ..................27
3.1.4.2 "Query Auxiliary Actuators" ................................... ............... 28
3.1.4.3 "Report Auxiliary Actuators" .................................. ...............28
3.1.4.4 "Set B behavior X .......................................................................... 28
3.1.4.5 "Query B behavior X ........................ ............................................. 29
3.1.4.6 "R report Behavior X ........................ ............................................29
3.2 Intelligent Prim itive D river Application............... ......................... ....... ....... 30
3.2.1 Fuzzy Logic ............... .... ......... ......... ........ 30
3.2.2 Functionality.................. ............................. 31
3.2.3 Program Logic ......... ..... ........ .. .. ........ ..... .............. 32
3.2.4 A scend Protocol 1 .................... ................. ...................... .............. 39
3.2.5 A scend Protocol 2 .................... ................. .................... .............. 39
3.2.6 Descend Protocol 1 ....... ........ .... .................................... .......... .. 41
3.2.7 D escend P rotocol 2 .............................................................. .............. 42

4 TESTING AND RESULTS ........................................................................ 43

4.1 Stair-C ounter A ssem bly ....................................................................... 43
4.1.1 Testing Procedure ............................................. .. .. .. ............ .. 43
4.1.2 R results ...................... ............ ........ 46
4.2 Auxiliary Track Positioning System ............................................... ................. 48
4.2.1 Testing Procedure .......................................... ..... ........... .... ........ 48
4.2.2 Results ........................... ........ .............. 50
4.3 H leading A lignm ent Controller ........................................ ......................... 52
4.3.1 Testing Procedure ............................................. .. .. .. ............ .. 52
4.3.2 R results ......................................... 52

5 CONCLUSIONS AND FUTURE WORK ...........................................................55

5.1 C onclu sions........................................... 55
5 .2 F u tu re W ork ..................................................................... 59

APPENDIX

A. STANDARD JAUS M ESSAGES ........................................ .......................... 61

A.1 Query Global Pose .. ................. ........................ ................ 61
A .2 Set W rench E effort .................................................... .................................. 61
A .3 JA U S C ore M message Set .......................................................................... .... 63

B. STAIR COUNTER MATHEMATICAL DEVELOPMENT ............................... 64

L IST O F R E F E R E N C E S ........................................................................ .....................69

B IO G R A PH IC A L SK E T C H ..................................................................... ..................71
















LIST OF TABLES

Table page

1-1 M message header data form at ............................................... ............................ 8

3-1 User defined input and output JAUS commands..........................................25

3-2 "Set Auxiliary Actuators" command fields.............. ....... ................27

3-3 "Query Auxiliary Actuators" command field................................ ............... 28

3-4 "Set Behavior X" com m and fields ........................................ ........ ............... 29

3-5 "Query Behavior X" command field ............................ .................................... 29

3-6 "Set Behavior" 1 and 2 control data ........................................ ...... ............... 32

A -i "Query G lobal Pose" data field ........................................ .......................... 61

A-2 "Set Wrench Effort" data fields .............. ............. ............... 62

A -3 Core m message set........ ...... .............................. ...... ............................. 63
















LIST OF FIGURES

Figure page

1-1 A architecture hierarchy .............................................................. ...... ... .

1-2 M message header properties bit layout ........................................ ...... ............... 9

2-1 Rem otec Andros robotic platform ......................................................................10

2-2 Andros physical dimensions ........... ..... ......... .... ............... 11

2-3 N active A ndros controller ......... ................. ..........................................................12

2-4 Communicator-Node Manager component interaction ........................... .........13

2-5 Primitive Driver component interaction..... ................... ...............14

2-6 Vehicle orthogonal coordinate system ........................................ ............... 15

2-7 Stair counter assem bly .......... ................... ....... ...................... ............... 16

2-9 M edian filter exam ple....................................................................... ..................18

2-10 Auxiliary track position system setup ........................................... ............... 20

3-1 Intelligent Primitive Driver implementation ................................. ................ 26

3-2 Intelligent Primitive Driver logic flow diagram.............. ..... .................33

3-3 "Set Auxiliary Actuator" algorithm .................................................. ............... 34

3-4 Opening sequence of "Set Behavior X" algorithm............................................35

3-5 Stair data representation ........................................ .............................................36

3-6 Skew alignm ent task correction........................................ ............................ 37

3-7 A scend stair m otion protocol....................................... ............... ............... 40

3-8 D escend stair m otion protocol ............................................................ ............ 41

4-1 Calibration data for Sharp GP2D12 infrared object detectors..............................44









4-2 Stair-counter testing assem bly........................................................ ............... 45

4-3 Stair-counter data........... ........ ........................................ ............ 47

4-4 Plumb compass attached to Andros auxiliary track...............................................48

4-5 Controller commanded halt angle and actuator halt angle versus operator
commanded angle.................... .................... ............ 50

4-6 Controller commanded halt error and actuator halt error versus operator
com m anded angle ............ ... ...................................................................... .. 5 1

4-7 Controller commanded halt heading and vehicle halt heading versus operator
com m anded heading ............. .. ............. ............ ...... ........ ............... 53

4-8 Controller commanded heading error and vehicle heading error versus operator
com m anded heading ............. .. ............. ............ ...... ........ ............... 54

5-1 Controller mounted on Andros platform ...................................... ............... 56

B -l Stair representation ........................... ............................ .. ........ .... ..... ...... 64

B-2 Stair runner model ............. .............. ................ .... ..... 65

B -3 Stair riser m odel .................. ................................. ..... ..... .. ........ 67

B-4 Calculated distances, d, for varying value of y..................................... .................68















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

DESIGN AND IMPLEMENTATION OF AN INTELLIGENT PRIMITIVE DRIVER

By

Peter M. Vinch, Jr.

August 2003

Chair: Carl D. Crane, III
Department: Mechanical and Aerospace Engineering

An Intelligent Primitive Driver (IPD) was designed to supplement the control of a

Primitive Driver component that is defined in the Department of Defense Joint

Architecture for Unmanned Systems (JAUS). Whereas the Primitive Driver component

accepts and blindly executes wrench commands, the IPD uses various subsystems to

provide it with the necessary information to make low-level decisions concerning vehicle

control. The IPD is accessible by either an onboard autonomous control system; or by a

tele-operational control system. Tele-operational control (teleop) is characterized by the

direct control of a platform by a human operator. For the case of an autonomous control

system, the IPD reduces high-level control responsibilities; and therefore reduces

processor demands. In the case of teleop control, the IPD serves to ease operator burden

by automating intensive operator-controlled processes.

The test platform for the functionality of the Intelligent Primitive Driver was a

Remotec ANDROS robot. In the case of the ANDROS robot, the IPD automates the

process of maneuvering up or down a flight of stairs.


















CHAPTER 1
INTRODUCTION AND BACKGROUND

1.1 Introduction

The purpose of this research was to design and develop an experimental intelligence

component based on the Joint Architecture for Unmanned Systems (JAUS), currently

being developed in concert with the Department of Defense. This component will be

designated the Intelligent Primitive Driver (IPD) and will allow for assisted tele-

operational (teleop) control of a platform. Teleop control can be defined as the control of

a vehicle or robot by the direct input of a human operator. Assisted teleop is based upon

this concept, but includes additional computer control to supplement the operator's

control; intensive control procedures were automated to ease the burden on the operator.

The IPD accomplished this task by having direct control of any and all actuators that

directly affect the motion of the platform. A Remotec Andros robot, outfitted with a

JAUS-compliant controller, was used to test the viability of the IPD. In the case of the

Andros, the IPD automated the complicated stair ascending and descending operations.

1.2 Background

1.2.1 Assisted Teleop Control

The human-machine relationship has always been clearly defined: machines are

controlled by humans and are constructed to ease the burdens of human life. However,

two recently developing factors have begun to dramatically change this relationship.









First, an increase in computing power and system reliability along with a decrease in size

and power requirements of modem control systems have made possible the shift of some

control responsibility from the human operator to the controller itself. Bayouth and

colleagues [1] (of the Robotics Institute of Carnegie Mellon University) constructed an

autonomous roadway vehicle that demonstrated lane following, speed and heading

compliance, and obstacle avoidance in an effort to increase vehicle safety and mobility.

Several other groups have also worked on the "Intelligent Cruise Control" concept. The

Mustererkennung und Szenenanalyse Pattern Recognition and Scene Analysis (MESA)

research group [2] have developed behaviors (such as tracking a lead vehicle or lane

changing) that comprise a basic control set on which more complicated procedures are

based. Schlegel [3], in his thesis, "Autonomous Vehicle Control using Image

Processing," tested the intelligent cruise control notion through the use of scale models

coupled with a remote control station aimed at emulating full-scale vehicle controls.

The second factor that has influenced the human-machine interface is the growing

complexity of the platforms being automated and the tasks they are able to perform.

Connell and Viola [4] (of the IBM T.J. Watson Research Center) have a novel way of

describing the problems with traditional platform control systems:

"Consider the differences between riding a horse and driving an
automobile. A horse will not run into a telephone pole at high speed. If
you fall asleep in the saddle, a horse will continue to follow the path that it
is on.... In general, horses are much smarter than automobiles and thus
provide a better model for control of a mobile robot." [4]

Connell and Viola constructed a platform and control system that cast the operator as an

agent in the control system, able to input commands into the arbitration network, as well

as a high-level command language that was able to shut out individual control agents.









Huntsberger and Rose [5], of the Jet Propulsion Laboratory (JPL) and the University of

South Carolina (USC), respectively, are working on a behavior-based control system

named BISMARC, or the Biologically Inspired System for Map-based Autonomous

Rover Control, for use with the Mars rover platforms. They utilize a form of path

planning that is derived from the study of human navigation through complex

environments.

1.2.2 Stair Climbing

For mobile robotic platforms to be useful in urban environments, they need to be able

to easily traverse commonly found terrain features, such as stairways. Several detection

methods are used to enable platform navigation on these non-continuous planar structures

(such as vision-based positioning and edge detection, laser-based edge detection, and the

fusion of several sensor systems). Others have solved the dilemma by manipulating the

physical characteristics of the platform to suite the special needs of a stair-climbing

vehicle.

Matthies, et al. [6] constructed a small mobile platform capable of performing

reconnaissance duties in urban situations. To meet the stair climbing requirements

associated with this detail, a vision-guided navigation and detection system was

implemented on the robot. A stereovision system was used to detect the forward edges of

individual steps. This information was used to derive the angle of rotation between the

robot and the stairway; and to ensure that the robot was accurately following the stair

heading.

Lewis and Simo' [7] (Iguana Robotics, Inc.) built a bipedal platform based on the

biomorphic concept capable of stair travel (Figure 1-1). Basically, a biomorphic robot

attempts to mimic the sensory capabilities of animals; sensory input is predicated upon









voluntary movement of the platform and must be distinguished from possible inputs

produced by the platform itself. The platform fused stereovision; and tactile and pressure

sensors to build an accurate data model of the terrain to traverse.

Another application of the biomorphic concept is the work of Talebi, et al. [8]. They

constructed a quadruped platform that has only one actuator per leg coupled with

compliant prismatic joints. Therefore, as an animal would, the platform climbs a stair

dynamically. As the leg contacts the stair, ground forces cause the joint spring to

compress; and the effective length of the leg is reduced.

Perhaps the most stable solution for the stair-climbing problem, when the

development of the platform permits, is to tailor the geometry to accommodate the stair

climbing motion. Lauria, et al. [9] took this approach in developing their vehicle,

Octopus. The platform consists of eight motorized, tactile wheels and a tilt sensor; and

has a total of fifteen degrees of freedom. The platform geometry allows for all eight

wheels to be in contact with the ground at all times, regardless of the terrain profile;

allowing for relatively simple travel of the platform across any uneven terrain, stairways

included.

1.3 The Joint Architecture for Unmanned Systems (JAUS)

This section provides a functional description of the Joint Architecture for Unmanned

Systems (JAUS). The technical constraints on the architecture, system topology,

standard component definition, and the JAUS message will be discussed.

1.3.1 Overview

The JAUS architecture is being developed in conjunction with the Department of

Defense in support of unmanned vehicle systems development and provides a means for

reducing system life-cycle costs by offering a well-defined component interface. This









interface allows for the future reuse of expensive components in developing autonomous

systems and also allows for the quick exchange of malfunctioning or outdated

components in current autonomous systems. Further, the engineer is free to place all

available resources into obtaining optimal performance from the component as its

interface is predefined [10].

The JAUS architecture is divided into three separate volumes: the JAUS Domain

Model, Document Control Plan, and Reference Architecture. The JAUS Domain Model

defines both known and prospective operational requirements of unmanned systems,

while the Document Control Plan describes the procedure used to recognize and track

changes to accepted JAUS documents. This work will focus solely upon the Reference

Architecture as it is concerned with aspects of component design. The reference

architecture defines components, messages and standards that classify a system paradigm,

which allows for the assimilation of distributed system architectures. The reference

architecture is comprised only of components and messages that have been technically

evaluated by the tech base, academia, or an industry source and whose implementation is

thoroughly understood. Therefore, the incorporation of components, their classification,

and their corresponding messages is an evolutionary process [10].

There are four technical constraints, which have been levied upon the JAUS

architecture to ensure that it may be freely applied to any classification of unmanned

system. These constraints are platform independence, mission isolation, computer

hardware independence, and technological independence. To be platform independent,

no assumptions concerning vehicle platforms to be automated will be incorporated into

the definition of any JAUS component. The JAUS architecture defines a mission as the









ability to gather information about or to alter the state of the environment in which the

platform is operating. Therefore, the mission isolation constraint is intended to allow the

engineer to construct systems that can support a variety of missions, not just a single one.

The computer hardware independence constraint insists that the component be designed

independent of the computer system upon which the component will run. This was

included in the architecture so that currently used components can be applied to future

computer systems without modification to the component. This allows new computer

architectures to be easily inserted into current systems, extending its life cycle. This also

allows for hardware flexibility, as the appropriate hardware may be applied to each

system. Finally, technological independence is similar to computer hardware

independence, but instead deals with the action to be performed by the component instead

of the system that is performing the action. This constraint basically states that the

architecture will make no assumptions concerning the method by which an action is

performed. For example, in a JAUS compliant position system, no assumptions are made

concerning the method in which the vehicle position is obtained. Any method of

obtaining vehicle position is allowable, from a Global Positioning System (GPS), dead

reckoning, inertial measurement, a vision based position system, or any subsequent

positioning system [10].

1.3.2 System Topology

There are four elements, which comprise the hierarchy of the JAUS architecture: the

System, Subsystem, Node, and Component/Instance. A System is a logical grouping of

one or more Subsystems, which have been grouped such that beneficial cooperation

between the Subsystems can be achieved. A Subsystem is a distinct organism, which is

comprised of any number of Nodes necessary to form a complete unmanned system. A









Node is a distinct entity, comprised of a single processor or multiple processors working

in conjunction with each other, to provide a complete service. Finally, a Component is a

cohesive software process, which runs on a Node. An Instance is a single occurrence of a

Component running on a Node. Several Instances of the same Component may run on a

single Node, and are delineated by unique addresses. Figure 1-1 illustrates the interaction

of these four levels [10] .


SYSTEM





Node Node Node Node




Figure 1-1: Architecture hierarchy (used from JAUS: Reference Architecture
Specification, pg. 12)

1.3.3 The JAUS Component

As JAUS is a hierarchical system of components with standardized interfaces, the

JAUS Component is a strictly defined entity. A distinct name and identification number

defines a JAUS Component and every JAUS Component shall perform a single, cohesive

function. Each Component must be able to accept and act upon the set of core JAUS

command codes, as well as the input and output codes specific to the individual

Component itself. A list of the core JAUS command codes may be found in Appendix A

[10].

1.3.4 The JAUS Message

A JAUS message is comprised of two distinct components: the message header and

the message data buffer. The message header completely defines the message's









destination node, component, instance and subsystem identification, and the message's

corresponding source information. The message header also consists of the JAUS

command code, the number of bytes in the data buffer that the destination component can

expect to receive, and information pertaining to the message properties, such as the JAUS

architecture version being used. The message header data is found in Table 1-1 while the

bit field layout for the message properties can be seen in Figure 1-2.



Table 1-1: Message header data format (used from JAUS: Reference Architecture
Specification, pg. 54)
Field # Field Description Size (Bytes)
1 Message properties 2
2 Command code 2
3 Destination instance ID 1
4 Destination component ID 1
5 Destination node ID 1
6 Destination subsystem ID 1
7 Source instance ID 1
8 Source component ID 1
9 Source node ID 1
10 Source subsystem ID 1
11 Data control (bytes) 2
12 Sequence number 2
Total Bytes 16


The message data buffer is composed of packed JAUS control data. Each command

code has control data associated with it that is used by the system to command

component behavior. In an effort to reduce the size of the JAUS messages being

transmitted, and therefore reduce the required bandwidth of the system, the message data

is compressed before being transmitted. To accommodate this, the JAUS code library for











each component and its subsequent command codes must have the ability to pack and


unpack the control data.


Version
Range 0..63

Version 2.0 = (

Version 3.0 = 1

2..63 unused


15 14 13
Most significant bit


Cn C
CD CD
CD CD

on
1. R.

0 0
CD CD
0 0
oo

o3


o
0


0



in


Message Priority
Range 0..15

Default Priority 6

Normal Priority Range
0..11

Safety Critical Range
12..15

1 1 1


8 7 6 5 4 3 2 1 0
Least significant bit


Figure 1-2: Message header properties bit layout (used from JAUS: Reference
Architecture Specification, pg. 54)


C-o
O >
C"




'v















CHAPTER 2
TEST PLATFORM DEVELOPMENT

To investigate the Intelligent Primitive Driver, a test platform first needed to be

outfitted with a JAUS compliant control system. Due to the availability of indirect

motion actuators on the system and its relatively complicated stair climbing procedures, a

Remotec Andros robot was chosen for this task.

2.1 Remotec Andros Robot

Figure 2-1 depicts the Remotec Andros robot. As stated in the instruction manual, the

primary design purpose of the Andros is "to provide an effective means for remote

Explosive Ordnance Disposal (EOD)... Andros robots are currently used to remotely

perform a variety of hazardous work tasks including explosive handling, tactical support

operations, and nuclear plant maintenance" [11].













Figure 2-1: Remotec Andros robotic platform

The robot consists of a main chassis, front and rear sets of auxiliary tracks, and the

main arm assembly. The tracks are made of Kevlar belts with molded internal and

external urethane cleats. The auxiliary tracks are able to swing from +85 degrees to -65









degrees relative to the horizontal position. The drive motors are able to propel the

Andros up forty-five degree slopes or stairs and can maintain the vehicle's position upon

a slope through dynamic braking. The physical dimensions of the Andros are seen in

Figure 2-2 [11].













32" 28"

Figure 2-2: Andros physical dimensions

Figure 2-3 depicts the native Andros controller. Upon power up of the Andros

system, the native control transmits an initialization string to the Andros' embedded

controller and then begins the continuous output of the control data. The Andros'

embedded controller will only enter the "ready" state and accept platform control data if

the initialization string is properly sent and the control data is received at a maximum 5

Hz frequency. The controller uses a proprietary serial control stream to communicate

with the Andros' embedded controller. The update frequency is the absolute maximum

rate at which any controller may update the control data being sent to the Andros and

therefore alter the Andros' intended motion.

To use the Andros robot as the test platform for the IPD system, the JAUS control

system implemented on the Andros had to be completely removable from the system so

that the native Andros controller could be reconnected and used to control the Andros.









To meet this interoperability constraint, the JAUS control system mimicked the serial

control stream of the native controller. To achieve this, the control stream and

initialization string were reversed engineered from the output of the native controller;

however, the specific information pertaining to the Andros control data bytes may not be

disseminated because of a nondisclosure agreement entered into between the Center for

Intelligent Machines and Robotics (CIMAR) laboratory, located at the University of

Florida, and Remotec, the manufacturer of the Andros platform.












.... .. .. .






Figure 2-3: Native Andros controller

2.2 Andros JAUS Controller

The Andros JAUS controller operates on a RabbitCore RCM3200 microcontroller,

which utilizes a Rabbit 3000 microprocessor running at 44.2 MHz. The RCM3200 has

an integrated 10/100Base-T Ethernet port and six available serial ports for

communications, as well as 44 configurable, 5 volt tolerant, I/O lines. The RCM3200

runs the Dynamic C Premier Version 7.33P3 real time operating system, in which the

four basic JAUS components that comprise the Andros control system were coded.









These components are the Communicator, Node Manager, Primitive Driver, and Position

System. Libraries for each component were coded following the specifications found in

the JAUS Reference Architecture.



Node A Node B

Component A Component B



Node Manager Node Manager



Communicator) Ethernet Communicator

Figure 2-4: Communicator-Node Manager component interaction

Two JAUS components are directly responsible for all inter-component

communications: the Communicator and the Node Manager. As such, all nodes must

support both a Communicator and a Node Manager component. The Communicator

allows for a single point of message entry into a subsystem while maintaining the data

link between the subsystems. The Andros Communicator uses a User Datagram Protocol

(UDP) Ethernet connection for all communications. The Node Manager component

controls the routing of JAUS messages from one node to another. As depicted in Figure

2-4, a JAUS message is spawned within a component and then sent to the Node Manager,

where the information pertaining to the destination component and destination node are

attached to the message. This fully defined JAUS message is now passed on to the

communicator, which handles the transmission of the message to the proper node [10].























Vehicle Specific
ctuator Commands


Figure 2-5: Primitive Driver component interaction

The Primitive Driver is a component, which accepts wrench commands from the

System Commander and resolves them into vehicle specific actuator signals, thus

initiating vehicle motion, as seen in Figure 2-5. A wrench command consists of six

propulsive and six resistive elements, with each set consisting of three linear force

elements and three rotational moment elements. These elements are then mapped to the

three axis orthogonal coordinate system assigned to the vehicle, as shown in Figure 2-6.

It is worth noting that every element of a wrench message is not necessarily applicable to

every vehicle. For example, a wheeled vehicle typically only requires three elements of

the wrench message to control it properly: the resistive and propulsive linear forces in the

x direction and the rotational moment in the z direction [10].









The Position System is concerned solely with the determination of the vehicle's

global position and orientation and is necessary for the controller to perform accurate

autonomous motion. The vehicle's position and orientation information is provided to

the system upon receipt of a "Query Global Pose" command from either the Operator

Control Unit or the Intelligent Primitive Driver.








Ground Plane






Figure 2-6: Vehicle orthogonal coordinate system

2.3 Sensor Systems

There are three main sensor systems used by the Andros system: the stair counter

assembly, the auxiliary track position system, and the JAUS positioning system. These

systems provide feedback essential to the controller's ability to execute behavioral

commands.

2.3.1 Stair Counter Assembly

For the stair-climbing algorithms to function properly, the control system needs to

know the relative position of the Andros on the stairs. Typically, a Global Positioning

System (GPS) would be used to provide location information in a robotic system.

However, staircases are found in or around buildings, which generally limit the

effectiveness of a GPS system; if satellite transmissions to the GPS receiver are blocked









by the structure housing the staircase, no position information will be acquired.

Therefore, the stair counter assembly was designed to provide the relative position of the

Andros upon the staircase by counting the number of stairs that the Andros has passed

and is able to account for a step while moving in either direction upon a staircase. For

example, while climbing the stairs, the Andros passes four steps. While attempting to

move to the fifth step, a slippage error occurs and the Andros slides back down two steps.

The stair counter is able to take this error into account and update the current position of

the Andros upon the stairs. In this case, the Andros would now be located at the second

step.

Mounting Plate



infrared
Sensors





\ Shroud












Figure 2-7: Stair counter assembly

The stair counter assembly consists of an array of two Sharp GP2D 12 infrared object

detectors. These sensors take continuous distance readings up to 80 cm, have an update










rate of 31.25 Hz, and are interfaced by the RabbitCore microcontroller through the use of

a TLC545 Texas Instruments analog-to-digital converter. The sensors are positioned one

in front of the other with a one-inch offset and are orientated such that their detection

beams are perpendicular to the long axis of the Andros, as seen in Figure 2-7; the sensors

point directly at the plane upon which the Andros is situated. Both sensors are shrouded

to limit the amount of interference they may receive from ambient light sources and from

each other.




0.4


0.2


0
S4.5 5 5.5 6 65

-0.2


.: -0.4


-. Impulse
mn -0.6
a *


-0.8


-1
Stair Data *
1st Derivative
-1.2
2nd Derivative

-1.4
Time (sec)

Figure 2-8: Infrared sensor stair representation








Each infrared sensor constructs a digital representation of the staircase as the Andros

moves on it by determining the distance from the sensor to the staircase. By assuming

that the vehicle maintains a relatively constant velocity upon the staircase, the derivative

of the stair data can be found by simply taking the difference of the current data point and

the previous data point collected. The second derivative of the stair data can now be

obtained by taking the difference of the first derivative data. Figure 2-8 depicts a sample

stair data representation for a single infrared detector and the corresponding first and

second derivative data. The graph has been cropped to emphasize the range of pertinent

data. The data for the stair representation was simulated using a mathematical model of

the sensor system, with the first and second derivative data obtained as outlined above.

For the simulation, the rise of a single step was set at 8 inches, the run was set at 10

inches, and a 0.1 second sampling rate was used. Derivation of the mathematical model

of the sensor system can be found in Appendix B.


Raw Data
4 3 5 4 9 5 1 4




3 3 4 4 1 1
SortedData 4 4 5 5 5 4

5 5 9 9 9 5



Filtered Data
Figure 2-9: Median filter example









To account for noise in the infrared detection signals, the first derivative data is

filtered using a three element median filter before the second derivative is calculated.

Median filtering is a non-linear filtering technique useful for the suppression of impulse

noise and the smoothing of edges. It works by taking a set number of data points and

determining the mathematical median of them, which then replaces the data point. An

example of a three element median filter is shown in Figure 2-9. In this example, three

elements of the raw data are grouped together and sorted from low to high. In this

configuration, the median of the data is simply the middle of the three numbers, which is

now the filtered data point [12].

The impulses in the second derivative data represent inflection points on the stairs;

the interior concave stair corer will yield a positive impulse while an exterior convex

stair corner will yield a negative impulse. The system accounts for the stairs that the

Andros has passed by detecting these impulses; if the impulse that is less than a given

threshold value, a stair is counted. The direction of travel upon the stairs, and therefore

whether to add or subtract a stair to the total number counted, is determined by which

sensor detected the impulse first. If the front detector senses the impulse before the rear,

then a stair is added. If the rear detector senses the impulse before the front, then a stair

is subtracted from the total.

The computation of the first and second derivatives of the stair representation and the

application of the median filter induces a delay in the detection of the stair inflections.

Each of the derivative computations account for a one-cycle delay, while the median

filter accounts for a three-cycle delay for a total delay of five cycles. As the detectors are










polled at a rate of 20 Hz, the total delay time is 0.25 seconds between acquisition of the

stair data and detection of a stair inflection.

The stair counter assembly also has an "end of world" capability, meaning that it can

be used for detection of drop-offs and ledges. The system uses this function to determine

the edge of a landing when descending a set of stairs. The edge is detected by monitoring

the output of the infrared sensors: the distances measured will remain constant until the

sensor reaches a point when it is directly over the first step. At this point, there will be a

drastic change in the measured distance, which the system interprets as the edge of the

landing and the beginning of the stairs.



1500



DWT
Andros /1 n
/ \ // Sensor
Chassis \--o
Sensor
Cable



-- - 650



Auxiliary
Track .
\ T- \ _Auxiliary
S/ Track
Assembly



00
Figure 2-10: Auxiliary track position system setup

2.3.2 Auxiliary Track Positioning System

A Draw-Wire Transducer (DWT) sensor, manufactured by UniMeasure, is used to

measure the angle of the Andros auxiliary tracks, one each for the front and rear tracks.









This sensor was used over other forms of angular sensors, such as rotary or optical

encoders, because of its ease of setup and robust mechanical interface; there are no gears

to become jammed with dirt or optical sensors to become inoperable because of grime.

The DWT is simply a spring-loaded potentiometer connected to a three-foot long cable.

The DWT sensor is attached to the chassis of the Andros, with the draw cable being

wrapped around the auxiliary track drum once and then attached to it via a 10-32 cap-

head screw. The setup is shown in Figure 2-10.

A 5-volt reference voltage is applied to the sensor, which will return from 0 to 5 volts

proportional to the length of cable drawn from the sensor. The governing equation for

the angle measured by the system is given in Equation 2-1, where Vhigh and Viow are the

upper and lower voltage bounds observed by the sensor and Vmeasured is the sensor

voltage.


measured l- ow / ^o0
0 m(ee Kow 1500 }(2-1)
high low)

The DWT sensors are interfaced by the RabbitCore microcontroller through the use

of a TLC545 Texas Instruments analog-to-digital converter.

2.3.3 JAUS Positioning System

As there is no GPS being used on the Andros system, the position system is

comprised solely of a PNI Corporation TCM2-20 tilt-compensated module to update the

Andros heading. The compass heading of the Andros is filtered using a three element

median filter, as previously described.

The TCM2-20 is based upon PNI Corp.'s proprietary triaxial magnetometer system

and its biaxial electrolytic inclinometer. When level, it is accurate to within +/- 0.5









degrees RMS with 0.1-degree resolution. This changes to +/- 1 degree RMS when the

system is on an incline. It communicates via a 38.6 kBaud, RS-232 serial connection and

is set to run at a sampling rate of 20 Hz.

The digital compass experiences a computation delay, much in the same manner as

the stair counter system. The three element median filtering produces a delay of three

cycles, which corresponds to a delay of 0.15 seconds between acquisition of the heading

data and realization of the filtered heading.

2.4 Operator Control Unit

In order for the Andros' JAUS control system to be fully operable, an Operator

Control Unit (OCU) was developed on a Gateway Solo 3350 laptop with the Linux

Redhat 8.0 operating system. A Netgear ME102 Wireless Access Point is used to

establish a wireless Ethernet connection with the Andros JAUS controller. The access

point uses the IEEE 802.1 lb standard and transmits up to 11 Mpbs at 2.4 to 2.5 GHz.

To be able to communicate with the JAUS components located on the Andros

platform, the OCU needed to have information pertinent to the construction of the JAUS

messages required to command these components available. Therefore, JAUS message

libraries for the Primitive Driver and Position System components were coded for the

Linux operating system. These libraries were adapted from code obtained from Dr. Jeff

Wit of Wintech, Inc. Communicator and Node Manager components were also coded for

the Linux operating system to allow the OCU to interact with the Andros' JAUS

components. All of the OCU components were developed in parallel with the

corresponding components used on the Rabbit microcontroller.

The OCU console was developed using the Linux Curses library. This was chosen

for the basis of the user interface because it allows for the easy manipulation of the






23


terminal display regardless of the terminal type used. The Curses library only supports

the use of single byte characters for display, but this was more than adequate to meet the

needs of this OCU.















CHAPTER 3
INTELLIGENT PRIMITIVE DRIVER DEFINITION AND APPLICATION

This chapter defines the Intelligent Primitive Driver (IPD) in terms of the JAUS

architecture. It then details the application of the Intelligent Primitive Driver to the

Andros system.

3.1 Component Definition

For the IPD to be considered a JAUS component, it needs to fit into the rigid

framework that comprises the architecture. Therefore, the component will be defined as

per the specifications detailed in the JAUS Reference Architecture: the component

function, input and output messages, and description will be defined. The component has

been assigned the component identification number of 99 [10].

3.1.1 Component Function

The Intelligent Primitive Driver component is responsible for the control of all

indirect motion related actuators. An indirect motion related actuator is any actuator that

affects the ability of a platform to perform a commanded motion, but does not perform

that motion itself. For example, on the Andros robot, the front and rear auxiliary tracks

are considered indirect motion actuators. They are responsible for aiding the Andros in

moving over rough and uneven terrain, but do not directly produce the motion.

3.1.2 Component I/O

The IPD will accept any of the JAUS core input and output messages, as well as the

"Set Wrench Effort" and "Query Global Pose" commands. These commands are as









defined in Appendix A. Table 3-1 shows the user defined set of input and output

messages and their corresponding unique command codes. The input and output

command sets will be completely defined in the "Input and Output Commands" section

later in this chapter.



Table 3-1: User defined input and output JAUS commands
Command Code Description
OxlFF1 Set Auxiliary Actuator
OxlFF2 OxlFF9 Set Behavior X
O x3FF1 Query Auxiliary Actuator
Ox3FF2 Ox3FF9 Query Behavior X
" Ox5FF Report Auxiliary Actuators
O Ox5FF2 Ox5FF9 Report Behavior X


3.1.3 Component Description

The IPD defines a command interface to control any available indirect motion

actuators available upon a platform and any subsequent set of vehicle behaviors that

would utilize these actuators. Further, the IPD is able to issue wrench commands to a

primitive driver component. Automation of vehicle behaviors is accomplished to ease

operator burden when the JAUS system is acting in tele-operational mode and to decrease

high-level processor load when the system is acting in full-autonomous mode. Similar to

the Primitive Driver component, the IPD does not imply any specific platform in its

definition and therefore is not completely defined until it has been applied to the control

system of a particular platform.

Figure 3-1 illustrates the most basic implementation of the Intelligent Primitive

Driver into the JAUS system architecture. The System Commander may send

commanded wrench efforts to the primitive driver to initiate vehicle motion or any of the









aforementioned IPD command codes to the Intelligent Primitive Driver either to control

an indirect motion actuator or start a vehicle behavior. If a command is sent to begin a

vehicle behavior, the IPD is able to send vehicle specific commands directly to the

vehicle to control the indirect motion actuators. Also, if vehicle motion is necessary to

accomplish the behavior, the IPD may send commanded wrench efforts to the primitive

driver component to incite vehicle motion.

System


System Commander



Commanded
Comade LIPD Command
Wrench Effort

Subsystem
C n CCommanded Q
Wrench Intelligent Pose
Primitive Effort Primitive se Pose
Driver -System
Driver Poseem
Data
Vehicle
Specific Indirect Motion
Actuator Actuator
Commands Commands

-* -

.. 'f'.^ -n tt


Figure 3-1: Intelligent Primitive Driver implementation









3.1.4 IPD Input and Output Messages

This section will define the set of user-defined input and output messages used by the

IPD.

3.1.4.1 "Set Auxiliary Actuators"

The "Set Auxiliary Actuators" message controls the indirect motion actuators

available on the platform. The command consists of four available linear actuator fields

and four available rotational actuator fields. Each field in the command may be mapped

directly to a single actuator of corresponding type, either linear or rotational, for control.

The interpretation of the numerical limits of the data fields allow for a wide array of

actuator control. The limits may be interpreted as a percentage of the maximum speed to

move the actuator at, a percentage of the maximum distance to move the actuator to, or

even interpreted as a blind forward/reverse/stop control message. The data fields and

vector-mapping table is for this command is found in Table 3-2.



Table 3-2: "Set Auxiliary Actuators" command fields
Field # Name Type Units Interpretation
See Mapping Table that
1 Presence Vector Unsigned Short N/A Follows
2 Aux Actuator 1 Scaled Integer
3 Aux Actuator 2 Short Integer Percent Lower Limit: -100
4 Aux Actuator 3 Upper Limit: 100
5 Aux Actuator 4
6 Aux Actuator 5 Scaled Integer
7 Aux Actuator 6 Short Integer Radians Lower Limit: -n
8 Aux Actuator 7 Upper Limit: 7t
9 Aux Actuator 8

Vector to Data Field Mapping for Presence Vector of Above Command
Vector Bit 7 6 5 4 3 2 1 0
Data Field 9 8 7 6 5 4 3 2









3.1.4.2 "Query Auxiliary Actuators"

The "Query Auxiliary Actuators" message will cause the IPD to reply to the

requesting component with a "Report Auxiliary Actuators" message. The command field

is shown in Table 3-3.



Table 3-3: "Query Auxiliary Actuators" command field
Field # Name Type Units Interpretation
See "Report Auxiliary Actuator"
1 Presence Vector Unsigned Short N/A Message


3.1.4.3 "Report Auxiliary Actuators"

The "Report Auxiliary Actuators" command message provides the receiving

component with the current values of the commanded "Set Auxiliary Actuators"

message. The message data and mapping of the presence vector for the "Report

Auxiliary Actuators" message are the same as the "Set Auxiliary Actuators" message, as

seen in Table 3-2.

3.1.4.4 "Set Behavior X"

The "Set Behavior X" message is used to initiate the behavioral control algorithms,

which are to be applied to the individual platform. The message has been issued the

command code range of OxFFF2 to OxFFF9 to allow for 8 vehicle specific behavior codes

to be applied to the control system. The corresponding behavior number, from 1 to 8,

replaces the 'X' in the command code names in the code definition. The data fields are

delineated into 4 unsigned integers and 4 full integers, giving the design engineer a wide

range of available variables to transmit any necessary behavioral data to the system, such

as latitude and longitude, heading, or distance to travel. As such, a specific behavior may









be defined by all, some, or none of the available data fields. The data fields and vector-

mapping table is for this command is found in Table 3-4.


Table 3-4:


"Set Behavior X" command fields


Field # Name Type Units Interpretation
See Mapping Table that
1 Presence Vector Unsigned Short N/A Follows
2 Behavioral Parameter 1
3 Behavioral Parameter 2 Unsigned Int N/A User defined fields
4 Behavioral Parameter 3
5 Behavioral Parameter 4
6 Behavioral Parameter 5
7 Behavioral Parameter 6 Float N/A User defined fields
8 Behavioral Parameter 7
9 Behavioral Parameter 8

Vector to Data Field Mapping for Presence Vector of Above Command
Vector Bit 7 6 5 4 3 2 1 0
Data Field 9 8 7 6 5 4 3 2


3.1.4.5 "Query Behavior X"

The "Query Behavior X" message will cause the IPD to reply to the requesting

component with a "Report Behavior X" message. The command field is shown in Table

3-5.


Table 3-5: "Query Behavior X" command field


Field # Name Type Units Interpretation
See "Report Behavior X"
1 Presence Vector Unsigned Short N/A Message


3.1.4.6 "Report Behavior X"

The "Report Behavior X" command message provides the receiving component with

the current behavioral data being performed by the platform. The message data and









mapping of the presence vector for the "Report Behavior X" messages are the same as

the "Set Behavior X" message, as seen in Table 3-4.

3.2 Intelligent Primitive Driver Application

An Intelligent Primitive Driver component must be applied to a vehicle to fully define

the functionality of the behavioral and auxiliary actuator controls as no vehicle specific

data is given in the JAUS definition of the component. This section will discuss the four

main areas that comprise the application of the IPD to the Remotec Andros test platform.

These areas include: a discussion of the basis of the intelligence used in the control

algorithms, the functionality of the component as it pertains to the Andros robot, an

explanation of the program logic used in the controller, and an explanation of the stair

motion algorithms used by the controller.

3.2.1 Fuzzy Logic

Professor Lotfi Zadeh at the University of California in Berkley developed fuzzy

Logic in 1965 as a method of processing data by allowing partial set membership rather

than classical precise set membership or non-membership. Fuzzy Logic is based upon a

human intelligence model; Professor Zadeh reasoned that people do not need precise,

numerical information as input and yet they are capable of highly adaptive control. As

intuitive as this approach of control may appear, it was not applied to an actual control

system until the 1970's, mainly due to inadequacies in small-computer capabilities at the

time [13].

Fuzzy Logic provides a simple way to arrive at a definite conclusion based upon

vague, ambiguous, noisy or imprecise information. The logic model focuses on what a

system should do rather than trying to understand how the system works and concentrates

on the problem rather than attempting to represent the system mathematically, which may









be impossible, especially in the case of nonlinear systems. Fuzzy Logic incorporates a

simple, rule-based "if X and Y then Z" problem solving control approach. This approach

relies upon an empirically based model, which is dependent on the design engineer's

control experience. The system is inherently robust as it does not require precise inputs,

can be designed to fail safely if an input is lost, and despite the possible wide variation of

the input signal, the output is always a smooth control signal. As the design engineer

defines the rules that govern the system, the controller can easily be modified to improve

or dramatically alter system performance. Finally, any sensor that presents the controller

with an indication of the system's actions, regardless of sensor cost or precision, is a

viable candidate for the fuzzy controller [13].

The fuzzy logic control model was applied to the four major intelligence functions of

the control system: the stair protocol arbiter, the platform alignment controller, the

auxiliary track controller, and the task used to realign the Andros upon the stairs after a

slippage error has occurred. Each of these functions will be discussed as they are

encountered in the descriptions of the control algorithms to follow.

3.2.2 Functionality

To utilize the control capabilities of the Intelligent Primitive Driver, the command

messages associated with the component must be completely defined to interact with the

platform. The "Set Auxiliary Actuators" command must be mapped to control the

platform's indirect motion actuators. Vehicle behaviors must be assigned a control

number corresponding to one of the available "Set Behavior" commands, the requisite

control data for the behavior must be defined and assigned to the proper command

variable and the behavioral algorithms themselves must be characterized and coded for

use.









As shown in Table 3-2, the "Set Auxiliary Actuators" command message has eight

assignable auxiliary actuators command fields. Following this convention, the front

auxiliary track of the Andros robot is denoted as "Aux Actuator 5" and the rear auxiliary

track is denoted as "Aux Actuator 6." These fields were chosen as the auxiliary tracks of

the Andros may be moved to a specific angle through the use of the Auxiliary Track

Position System, described in Chapter 2.3.

The behavioral controls of the IPD are used to control the motion of the Andros on a

set of stairs, both ascending and descending. The ascending motion behavior has been

mapped to "Set Behavior 1" with the descending motion mapped to "Set Behavior 2."

Both behaviors use the same the control data variables, which have been assigned to the

data fields shown in Table 3-6.



Table 3-6: "Set Behavior" 1 and 2 control data
Field # Name Description
2 Behavioral Parameter 1 Rise of a Single Step (in.)
3 Behavioral Parameter 2 Run of a Single Step (in.)
4 Behavioral Parameter 3 Total Number of Steps
5 Behavioral Parameter 4 Not Used
6 Behavioral Parameter 5 Stair Heading (degrees)
7 Behavioral Parameter 6 Not Used
8 Behavioral Parameter 7 Not Used
9 Behavioral Parameter 8 Not Used


3.2.3 Program Logic

Figure 3-2 depicts the logic flow diagram of the Intelligent Primitive Driver upon

startup. This diagram is only representative of the Intelligent Primitive Driver and not

the JAUS system on the whole. The receipt and execution of JAUS commands by

standard components have been omitted because, for these instances, the controller









behaves in a manner consistent with a standard JAUS controller. Upon startup of the

Andros controller, the IPD enters a "ready" state and awaits the reception of an IPD

command message. The receipt of one of these commands causes the IPD to assume

control of the Andros and execute the desired commanded function.


Start Controller



Ready State



Command No
sg Recv'd?

Yes


Execute
Command




Command\ No
Completed?

Yes

Figure 3-2: Intelligent Primitive Driver logic flow diagram

Upon receipt of a "Set Auxiliary Actuators" command, the IPD moves into the

algorithm as shown in Figure 3-3. The IPD uses the Auxiliary Track Positioning System,

as outlined in Chapter 2.3, to determine the current angle of the auxiliary track. Once the

current angle has been determined, the algorithm checks to see in which of three possible

fuzzy sets the current track angle lies: less than the desired angle, greater than the desired

angle, or around the desired angle. The IPD will determine the direction, if any, to rotate

the track dependent upon which set the current track angle lies. If the current track angle









is less than the desired track angle, the track is rotated counterclockwise. If the current

track angle is greater than the desired track angle, the track is rotated clockwise. If the

track angle is equal to the desired track angle, within an angular tolerance of +/-1 degree,

the track is not rotated and the controller IPD returns to the ready state. The two-degree

total tolerance was determined heuristically based upon the maximum update rate of the

controller, the precision of the Auxiliary Track Positioning System and the overall speed

of motion of the auxiliary tracks while rotating. This algorithm is followed independent

of which auxiliary track is commanded to move.


Figure 3-3: "Set Auxiliary Actuator" algorithm









Upon receipt of a "Set Behavior" command, the IPD executes the algorithm shown in

Figure 3-4. The IPD calculates the total dimensions of the stairs from the control data

received along with the command, as seen in Table 3-6. Through simple geometric

equations, the IPD determines the total length, L, and pitch angle, P, of the stairs, as seen

in Figure 3-5. Next, the IPD aligns the heading of the Andros platform with the heading

of the staircase.


Figure 3-4: Opening sequence of "Set Behavior X" algorithm









The align platform function is another of the fuzzy logic functions. It calculates the

difference between the reported stair heading and the current heading of the Andros,

obtained from the Andros' onboard digital compass. The absolute value of the difference

is then compared against the defined fuzzy sets.







Total Length

Total Rise

Run -


Rise

Total Run
Figure 3-5: Stair data representation

If the absolute value is greater than 90 degrees, the Andros is rotated at its maximum

speed. If the absolute value is between 90 and 60 degrees of error, the Andros is rotated

at 75% of its maximum speed. If the absolute value is between 60 and 25 degree of error,

the Andros is rotated at 50% of its maximum speed. Finally, if the absolute value is less

than 25 degrees, the Andros is rotated at 25% of its maximum speed. This function has

an allowable angular tolerance of +/-4 degrees. The direction of the commanded rotation

is also dependent upon a fuzzy interpretation of the angular difference. If the absolute

value of the difference is less than 180 degrees and the actual difference is negative, the

Andros is rotated counterclockwise at the desired speed. If the absolute value of the

difference is less than 180 degrees and the actual difference is positive, the Andros is

rotated clockwise at the desired speed. The direction of rotation relative to the actual









value of the difference is reversed if the absolute value of the difference is found to be

greater than 180 degrees. This ensures that the Andros takes the shortest route possible to

reach the commanded heading.

Once the Andros has been aligned, the IPD starts the skew alignment task. This is a

separate program thread, which runs parallel to the main stair control thread. The

purpose of the skew alignment task is to detect and counter any angular slippage of the

Andros upon the staircase. Slip detection is accomplished by monitoring the difference

between the current heading of the Andros and the heading of the stairs, similar to the

align platform function.



Direction of Slip














Direction of
Adjustment

Figure 3-6: Skew alignment task correction

If an angular slippage error is detected, the skew alignment task counters it by

rotating the Andros in the direction opposite of the slippage. (Figure 3-6) This, again, is

a fuzzy logic task as the slippage error is grouped into broad sets of possible angular

error. If the error is greater than 5 degrees but less than 10, the Andros is rotated at 15%









of its maximum speed. If the error is between 10 and 25 degrees, the Andros is rotated at

25% of its maximum speed. At greater than 25 degrees, the error begins to approach a

non-recoverable state, and the Andros is stopped so that appropriate measures can be

taken to safely move it off of the staircase. Once the heading error is less than the 6

degrees of angular tolerance, the Andros rotation is halted. The linear motion control

command of the Andros is never affected by the skew alignment task, except for the case

in which the error is greater than 25 degrees, as the Andros' embedded controller allows

for both linear and rotational motion components to be commanded at the same time.

After the skew alignment task has been spawned, the IPD begins the stair counter

task. The stair counter task uses the stair counter assembly, as described in chapter 2.3,

to count the number of steps the Andros has successfully passed and also to account for

any possible linear slippage error. The number of steps must be counted to provide the

IPD with the relative position of the Andros upon the staircase to trigger stair motion

events, such as auxiliary track motions.

The next step for the IPD to complete is to determine which stair protocol should be

evoked. This is accomplished by determining if the total length, L, of the staircase is less

than or greater than the critical length. The critical length is defined as 1.5 times the total

length of the Andros. If the total length is less than the critical length, protocol 1 is

chosen. If the total length is greater than the critical length, protocol 2 is chosen. The

reason for the demarcation between the two protocols is simple: a staircase with a total

length equal to or less than the critical length simply does not have enough available

length to adequately carry out the full range of stair climbing motions. Also, the majority

of the stair motions are meant to ensure that the Andros is stable upon the staircase and









that the tracks do not lose traction. This is not a concern on short staircases as it is on

longer ones.

It should be noted that the portion of the stair motion algorithm, as seen in Figure 3-4,

is the same for both the ascend and the descend behavior commands. Also independent

of the direction of travel upon the stairs is the protocol arbiter. Protocol 1 is designated

for control of the Andros on a set of stairs less than the critical length in both the ascend

and descend commands, protocol 2 corresponds to control of the Andros on a set of stairs

longer than the critical length in both the ascend and descend commands.

Once the stair protocol has been carried out, the controller reverts back to its ready

state and awaits further commands from the System Commander.

3.2.4 Ascend Protocol 1

This stair motion protocol deals with the situation in which the total length of the

staircase is less than the critical length. First, the front auxiliary tracks of the Andros are

aligned with the angle of the stairs, P. (Figure 3-7a) Then, the Andros is simply started

up the staircase. The protocol concludes as the Andros passes the last step of the

staircase and is safely situated on the top landing, as seen in Figure 3-7c.

3.2.5 Ascend Protocol 2

The second ascend stair motion protocol deals with the situation where the total

length of the staircase is longer than the critical length. In this situation, the full range of

control steps are necessary to ensure that the Andros makes it safely to the top of the

staircase. The first stage of the process is to align the front auxiliary tracks of the Andros

with the angle of the stairs, 0, and the rear auxiliary tracks parallel to the ground. (Figure

3-7a) This stage occurs while the Andros is preparing to climb the staircase, therefore








there are no steps associated with it. In the next stage, the Andros is started up the

staircase. After two steps have passed, the front auxiliary tracks are aligned parallel with

the line of the stairs, as seen in Figure 3-7b. The Andros continues on in this third stage

alignment until the last step of the staircase is reached. As this step is reached, the last

stage is initiated. The front auxiliary tracks of the Andros are moved downward to catch

the Andros as it passes the apex of the stairs. This can be seen in Figure 3-7c.





a)



2 f

c;3 T r


Figure 3-7: Ascend stair motion protocol: a) Align front auxiliary tracks with stair
angle; b) Andros moving on stairs; c) Andros moving over apex of stairs


r\/rd









3.2.6 Descend Protocol 1

As with ascend protocol 1, descend protocol 1 is evoked when the total length of the

staircase to be traversed is less than the critical length. The Andros is moved to the edge

of the staircase and the front auxiliary tracks are moved downward to catch the Andros as

it crosses the apex of the stairs, as seen in Figure 3-8a. Next, the Andros is simply driven

over the edge of the steps and the front auxiliary tracks are moved parallel to the ground

plane. Once the Andros has reached the floor level, it is moved away from the staircase.


Figure 3-8: Descend stair motion protocol: a) front auxiliary track moved to catch
Andros; b) rear auxiliary track moved to push Andros over apex; c) align
front auxiliary track with stairs; d) front auxiliary tracks moved to catch
Andros at stair landing









3.2.7 Descend Protocol 2

Descend protocol 2 occurs when the total length of the staircase to be traversed down

is longer than the critical length. The Andros is moved to the edge of the stairs and the

front auxiliary tracks are moved downward to catch the Andros as it crosses the apex of

the stairs. (Figure 3-8a) While this is occurring, the rear auxiliary tracks are moved

downward to help rotate the Andros down to the plane of the staircase. (Figure 3-8b) The

Andros is moved forward until the main tracks come in contact with the stairs, as seen in

Figure 3-8c. The controller uses the "end of world" capability of the stair counter

assembly to determine the edge of the stairs, as discussed in Chapter 2.3. The Andros is

moved further forward and rear auxiliary tracks are moved to a horizontal position. The

Andros is moved down the steps until the third to last step is reached. Then, the front

auxiliary tracks are moved to parallel to the ground plane, which allows the Andros to

make an easy transition to the plane of the floor. (Figure 3-8d) The Andros is then

moved off and away from the staircase.















CHAPTER 4
TESTING AND RESULTS

This chapter describes the testing of the individual subsystems associated with the

Andros' Intelligent Primitive Driver (IPD). Testing procedures and results will be

reported for the stair-counter assembly, the auxiliary track positioning system and the

heading alignment controller.

4.1 Stair-Counter Assembly

4.1.1 Testing Procedure

The stair counter assembly was tested to ascertain whether or not the concept would

accurately count the number of stairs the platform has passed and therefore, be a viable

addition to the positioning system. The first step to accomplish this task was to calibrate

the infrared sensors that the system uses. This was done to correlate the values returned

from the analog-to-digital converter (ADC), which are used to interface the Sharp

GP2D12 infrared object detectors and the Rabbit RCM3200 microcontroller, to their

corresponding distances. To do this, a target was first placed a known distance away

from the infrared sensor. Then, one hundred readings of the value returned from the

infrared sensor through the ADC were recorded and their average obtained. The target

was then moved to another known distance and the average value was again found. This

process was repeated for distances measuring 4, 6, 8, 10, 12, 14 inches. The data points

were plotted using Excel and several regression curves were applied to determine which

type best fit the data. It was determined that the non-linear power function shown in










Figure 4-1 best described the output. The equation shown was then used in the code to

convert the ADC readings to distances for the testing.


SR' =0.9974

80


60


40


20


0
0 2 4 6 8 10 12 14
Distance (in)

Figure 4-1: Calibration data for Sharp GP2D12 infrared object detectors

Once the infrared sensor had been calibrated, a method of gathering the test data from

the staircase needed to be devised. To accomplish this, a testing frame made from 80/20

extruded aluminum framing system was constructed. The 80/20 was chosen for this task

as it was easily assembled and the extruded grooves were ideal for constraining the

motion of the test sled along the major axis of the stairs. The test sled housed the Rabbit

microcontroller as well as one of the Sharp GP2D 12 infrared object detectors to acquire

the range data. The sled was then tethered to a 12-volt gear motor to pull it along at a









relatively constant velocity. The entire assembly was placed upon the stairs, as seen in

Figure 4-2.






















Figure 4-2: Stair-counter testing assembly

The system recorded a reading of the range data from the surface of the staircase to

the infrared sensor once every 50 milliseconds. This delay was chosen, as it is longer

than the 32-millisecond update rate of the infrared sensors and therefore ensured that no

duplicate readings were accidentally recorded by the system. The microcontroller then

determined the first derivative of the data, applied a three element median filter to it, and

then determined the second derivative. A Dell Inspiron 8100 laptop computer then

recorded this data set. Communication between the Dell and the Rabbit were made via

the 57.6-kBaud connection provided for diagnostic purposes by the microcontroller. The

test was run a total of ten times on two separate staircases.

The stair-counter testing also had a secondary purpose: to empirically determine a

second derivative threshold value for the stair-counter control code. The stair-counter









code uses the second derivative values to determine if a stair has been passed and should

therefore be counted. However, detecting a single second derivative value for this

purpose is futile; a range of second derivative values that correspond to a stair edge may

be encountered. The system may also experience subtle negative second derivative peaks

due to uneven motion of the Andros upon the stairs. To account for all of this, the second

derivative value is compared to a threshold value. If the value is less than the threshold,

it is determined to be a stair edge and is counted.

4.1.2 Results

The data collected from the stair-counter testing rig was placed into an Excel

spreadsheet for graphing purposes. The data was analyzed to determine when the second

derivative of the stair representation occurred with respect to the recorded inflection

point, or outside edge, of the stairs.

Figure 4-3a illustrates the first set of sample data from the acquired from the testing.

The dark blue line represents the detected outline of the staircase, while the red line

represents the calculated second derivative of this data. Clearly visible are the two large

negative impulses, each one corresponding to one of the stair peaks shown. As designed,

each impulse is logged 0.25 seconds after the stair peak is experienced. The same is true

of Figures 4-3b and 4-3c; each one has two large, negative impulses that occur 0.25

seconds after their corresponding stair peaks are detected. Also, in each of these figures,

the negative impulses are less than -0.2, while none of the tertiary negative impulses

approach this value. Therefore, this was determined to be the optimum threshold value

for the system to use.








47
a) Stair Data Representation and 2nd Derivative Data, Samplel



10 1
9 0.8
8 Dt-0.6
S7 .-_ % 0.4
6 0.2
5- 0



2 Stair Data -0.6
1 e 2nd Derivative -0.8
0 -1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Time (Sec)


b) Stair Data Representation and 2nd Derivative Data, Sample 2



10 1
9 f0.8
8 0.6
7 0.4
6" 0.2
5 0
4- 4-0.2
o 3 Stair Data -0.4
2 2nd Derivative -0.6
1 -0.8
0 -1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Time (sec)


c) Stair Data Representation and 2nd Derivative Data, Sample 3


10 1
9 -- 0.8
8- 0.6
7 W -, 0.4
6 0.2
5 5 a% Wo .

4 -0.2
3 W- O -0.4
2 Stair Data -0.6
1 -0.8
1 2nd Derivative
0 -1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Time (sec)


Figure 4-3: Stair-counter data: a) sample 1, b) sample 2, c) sample 3









4.2 Auxiliary Track Positioning System

4.2.1 Testing Procedure

The setup for the auxiliary track positioning system testing had two steps. First, the

maximum and minimum values returned to the system by the Draw Wire Transducer

(DWT) were obtained. These values are used in conjunction with Equation 2-1 to

convert the measured DWT value to an angular measurement. The maximum value

occurs when the auxiliary track has been rotated to its topmost point, while the minimum

value occurs when the auxiliary track has been rotated to its bottommost point; these

points correspond to 150 degrees and 0 degrees, respectively. At each of these two

points, one hundred values of the DWT were taken and then an average value was

obtained.


Figure 4-4: Plumb compass attached to Andros auxiliary track









The second step in the setup was to affix a plumb compass to the auxiliary track so

that an independent angle measurement of the position of the track could be made. A

plumb compass is comprised of a needle, weighted at the bottom, along with an

adjustable faceplate. By attaching the body of the plumb compass to a structure, the

relative angle of the structure with respect to ground may be found when the structure is

rotated. The Andros auxiliary tracks were rotated to their bottommost point and the

adjustable face of the plumb compass was then adjusted such that the compass needle

pointed to 0 degrees. In this configuration, the compass needle pointed to 150 degrees

when the auxiliary tracks were rotated to their topmost position, which corresponds to the

measurement convention utilized by the controller. Figure 4-4 illustrates the plumb

compass attached to the Andros' auxiliary track.

To test the commands for the auxiliary track positioning system, the Operator Control

Unit (OCU) was used to send the experimental JAUS message, "Set Auxiliary

Actuators," to the Andros' JAUS controller, along with a commanded angular position of

the auxiliary track. The initial set of commanded angles were used to determine the

minimum allowable tolerance that could be used by the system without the system

becoming unstable. In this case, the system would be unstable if the controller

continually reversed the direction of the auxiliary track in an attempt to move the track to

the desired angle and be within the given tolerance. The minimum allowable tolerance

for the system was found to be +/- 1 degree. Following this, another set of "Set Auxiliary

Actuators" commands were sent to the system and the commanded angle, the angle

returned by the DWT sensor, and the angle read off of the plumb compass were recorded.










4.2.2 Results

Figure 4-5 shows a plot of the controller commanded halt angle and the actuator halt

angle versus the commanded angle sent to the controller from the OCU. The controller

commanded halt angle is the angle returned to the controller from the DWT sensor at the

instant that the controller issued the halt rotation command. The actuator halt angle is the

angle read from the plumb compass and corresponds to the angle of the auxiliary track

after the rotation has actually stopped. Both sets of data points have a linear distribution

across the entirety of the available range of motion, as illustrated by the applied trend

lines and their respective R2 values. The controller commanded halt angle and the

actuator halt angle are identical at 0 degrees and 150 degrees because there are physical

stops at these points of rotation on the Andros frame.

150 -
140
130
120
110
100
Sy = 1.0x + 0.4 *
a 90 -
SR = 0.9998
S80
S70 y 1.0.x- 1.6
70 2
S60 R= 0.9921
50
40 Actuator Halt Angle
30 0 Controller Commanded Halt Angle
20 -Actuator Halt Angle
10 Controller Commanded Halt Angle
04
0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150
Commanded Angle (Degrees)
Figure 4-5: Controller commanded halt angle and actuator halt angle versus operator
commanded angle













Figure 4-6 depicts a plot of the error between the commanded angle sent from the

OCU and the controller commanded halt error and the actuator halt angle. The controller

commanded halt error is the error between the commanded angle and the auxiliary track

angle at the instant that the controller issued the halt command and is recorded from the

DWT sensor. The actuator halt error is the error between the commanded angle and the

auxiliary track angle after the track actually stops and is recorded from the plumb

compass. The average error value returned from the DWT sensor is 0.5 degrees with a

standard deviation of 0.3, whereas the average error value returned from the plumb

compass is 3.4 degrees with a standard deviation of 2.2.


9.U
8.0
7.0
6.0
5.0

5.0 -*
4.0

3.0
' 2.0
1.0










-0.0
.o Q 10 0 60 ^ 80 90 100 110 120 130 140



-5.0



-6.0- Controller Commanded Halt Angle Error
-7.0--
Actuator Halt Angle Error
-8.0--
-9.0

Commanded Angle (Degrees)
Figure 4-6: Controller commanded halt error and actuator halt error versus operator
commanded angle









4.3 Heading Alignment Controller

4.3.1 Testing Procedure

The first step necessary to test the heading alignment controller was to calibrate the

PNI Corporation TCM2-20 digital compass. A serial connection was established

between the digital compass and a Dell Inspiron 8100 laptop computer and the digital

compass was placed into polling mode. Then, the compass was given the command to

start its calibration cycle and the Andros was slowly rotated in a circle for approximately

four minutes. Once this was completed, a series of "Set Behavior 1" commands were

sent from the OCU to the Andros JAUS controller, along with the desired heading. The

JAUS controller was coded such that the "Set Behavior 1" command initiated the heading

alignment code. The first series of tests were administered to determine the minimum

allowable tolerance value that the system could accept without the system becoming

unstable. In this situation, the system would be unstable if the controller continually

reversed the rotation of the Andros in an attempt to move the Andros to the desired

heading. From these initial tests, the allowable tolerance for the system was found to be

+/- 4 degrees. After this was completed, another set of "Set Behavior 1" commands were

sent from the OCU and the commanded heading, compass heading, and final Andros

heading were recorded. The compass heading is the value that the digital compass last

reported to the controller to illicit a stop rotation command. The final Andros heading is

the compass measure of the heading of the Andros when the rotation actually stops.

4.3.2 Results

Figure 4-7 depicts a plot of the controller commanded halt heading and the vehicle

halt heading versus the desired heading sent from the OCU. The controller commanded

halt heading is the heading returned to the controller at the instant that the controller










issues a stop vehicle rotation command. The vehicle halt heading is the heading of the

vehicle when the vehicle actually stopped its rotation. Both sets of data have a linear

distribution across the entire range of rotation, as illustrated by the applied trend lines and

their respective R2 values.


360
340
320
300
280
260
24 240
^ 220
0 y = 0.9x + 2.2
200
180 R = 0.9992
160
e 140
Z 120
100 Vehicle Halt Heading

80 W Controller Commanded Heading
60
SVehicle Halt Heading
40
420 y= 1.Ox 3.2 Controller Commanded Heading
20
0 ...... ... 0.R 60.9 67 .
0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360
Desired Heading (Degrees)
Figure 4-7: Controller commanded halt heading and vehicle halt heading versus
operator commanded heading

Figure 4-8 depicts a plot of the controller commanded heading error and the vehicle

heading error versus the desired heading sent from the OCU. The controller commanded

heading error is the error between the desired heading and the heading of the vehicle

when the controller issues a stop rotation command. The vehicle heading error is the

error between the desired heading and the heading of the vehicle when its rotation is

actually stopped. The average error value for the controller heading is 2.8 degrees with a







54


standard deviation of 0.8, whereas the average error value for the final Andros heading is

5.9 degrees with a standard deviation of 1.7.


10
9
8


6 -


4 -


2
1
0
-1 60 120 180 240 300 3i0
-2 0
-3 -
-4
-5
-6
-7 -
Vehicle Heading Error
-8
-9 4 Controller Commanded Heading Error
-10

Heading (Degrees)
Figure 4-8: Controller commanded heading error and vehicle heading error versus
operator commanded heading















CHAPTER 5
CONCLUSIONS AND FUTURE WORK

5.1 Conclusions

This research focused on the development of the Intelligent Primitive Driver (IPD),

an experimental, low-level, intelligence component for the Joint Architecture for

Unmanned Systems (JAUS). Three objectives were necessary to accomplish this task.

First, the IPD had to meet the criteria of a fully defined, standard JAUS component.

Second, a testing platform had to made JAUS compliant and the functionality of the IPD

had to be applied to the testing platform. Finally, the intelligence components of the IPD

that were applied to the testing platform had to be tested.

A standard JAUS component is defined through four criteria: the function of the

component, the accepted input and output messages that the component may handle, and

the full description of the component. In these terms, the IPD was fully constrained to

the JAUS architecture. The purpose was defined as being responsible for the control of

all indirect motion related actuators. A full set of input and output messages were

defined to meet the JAUS message standards. The component description defined the

implementation of the IPD into the JAUS architecture, set the IPD's unique component

identification number at 99, and discussed the specifics of the IPD's functionality.

A Remotec Andros robot was chosen as the testing platform because of the indirect

motion actuators located on the chassis and its complicated behavioral controls, namely

stair-climbing. A complete JAUS controller was developed specifically to be used by the









Andros platform; an Operator Control Unit (OCU), Primitive Driver, Node Manager,

Position System and Communicator components were coded for both the Rabbit

RCM3200 microcontroller with the Dynamic C operating system and the Gateway Solo

3350 laptop with the Linux Redhat 8.0 operating system. The Rabbit was used as the

Andros' JAUS controller, while the Solo 3350 was used as the OCU. The Intelligent

Primitive Driver was applied to the Andros platform: the IPD's capability to control

indirect motion actuators were mapped to the auxiliary tracks of the Andros and the

behavioral control commands were mapped to the stair ascending and descending

procedures. The proprietary Andros control stream was reverse engineered from the

native Andros controller and then applied to the Primitive Driver and Intelligent Primitive

Driver. As such, the Andros' JAUS controller was able to accept and interpret JAUS

commands and incite the Andros to act upon these commands accordingly. The

controller, as mounted on the Andros platform, can be seen in Figure 5-1.


Figure 5-1: Controller mounted on Andros platform









The intelligence components of the Intelligent Primitive Driver were tested to ensure

that they adequately performed the desired control function. A testing frame was

constructed to constrain the motion of a sled housing one of the Sharp GP2D 12 infrared

object detectors so that the stair-counter assembly could be tested. From the data

gathered from the system, it was shown that the negative second derivative impulses

could be observed by the system and that they did indeed lag the detection of the outside

stair edge by 0.25 seconds, as designed. The auxiliary track positioning system was

tested to determine if the final angular placement of the auxiliary tracks coincided with

the desired angular command. It was found that the average error value for the controller

commanded halt angle was 0.5 degrees with a standard deviation of 0.3, whereas the

average error value for the actual auxiliary actuator position was 3.4 degrees with a

standard deviation of 2.2. The minimum allowable tolerance for this control system was

+/- 1 degree. The heading alignment controller was tested to determine if the final

heading of the Andros coincided with the desired heading command. It was found that

the average error value for the controller commanded halt heading was 2.8 degrees with a

standard deviation of 0.8, whereas the average error value for the actual halt heading of

the Andros was 5.9 degrees with a standard deviation of 1.7. The minimum allowable

tolerance for this control system was +/- 4 degrees. Both of these control systems

performed as designed and returned favorable data when the limitations inherent to the

Andros platform were taken into account.

The discrepancies between the DWT and plumb compass error in the auxiliary track

positioning system and the final heading and compass heading error in the heading

alignment controller are a direct manifestation of the limitations of the Andros system.









As discussed in Chapter 2, the maximum update rate of the Andros control stream is 5

Hz. In terms of autonomous computer controllers, 0.2 seconds is a relatively long

amount of time. In both the auxiliary track positioning system and the heading alignment

controller tests, the controller commanded a halt of system motion that was not acted

upon until at least 0.2 seconds later. This fact translated into an average difference of 2.9

degrees for the auxiliary track positioning system and an average difference of 3.1

degrees for the heading alignment controller. Therefore, when the controller believes it

has reached the desired command position and has thus stopped the motion of the

Andros, the Andros is in actuality continuing to move. It is for this reason that the

Andros stair motion behavior has been broken down into its component parts and these

parts have been tested individually, instead of simply testing the Andros stair motion

controller in its entirety; it is entirely within the realm of possibility that the Andros

would incur a non-recoverable, fatal error when attempting to negotiate a staircase even

though the controller recognized the error and attempted to correct it.

The Andros is able to negotiate a set of stairs when controlled by a human operator

with a more reasonable expectation of a successful conclusion than with the JAUS

controller for two reasons, though it is still a very difficult and complicated task. First, in

terms of human control, 0.2 seconds is a relatively long amount of time. Second, the

human operator has both control experience and predicate knowledge of the system.

Therefore, the human operator can make predictive assumptions concerning the stair

motion process that the JAUS controller is unable to make. For example, the human

operator can take into account the type of stair to be traveled upon, the condition of the

Andros' tracks, and the amount of traction that the Andros is exhibiting when actually on









the stairs to make corrections to the stair motion process. With this incarnation of the

IPD, these predictive capabilities are not present.

5.2 Future Work

To increase the controllability of the Andros-IPD system, upgrades need to be made

to several of the subsystems. First, and most importantly, the Andros embedded

controller should be updated to a more modern control scheme. The outdated controller

and its 1200-Baud connection should be replaced by a modern microcontroller utilizing a

secure Ethernet connection protocol, such as the Transmission Control Protocol (TCP).

This replacement would solve the control problems, which currently inhibit the system.

When making this update, the current drive motors and auxiliary track positioning motors

should be replaced with motors that have integrated rotary encoders. This would serve

two purposes. First, the encoders located on the driver motors could be utilized to add

dead-reckoning capability to the current position system. With this, specific information

concerning the total movement of each individual track could be collected and used for

more exact vehicle placement. Second, the encoders on the auxiliary track positioning

motors could replace the Draw Wire Transducers (DWT) currently used to acquire

auxiliary track position. The DWT sensors work very well, but are susceptible to

environmental conditions and hazards; the internal encoders would not have this potential

problem. The Intelligent Primitive Driver should be modified to include adaptive control

capabilities to the stair motion algorithms. Concepts of neural networks could be applied

to the controller to give it the ability to learn from stair motion trials. This would allow

the system to adapt the stair motion algorithms to work more efficiently on different

types of stairs. For example, the controller could determine if an auxiliary track should






60


be moved at a different point during the stair motion algorithm or change the correction

speeds used to correct the Andros if it slips on the staircase.

Finally, the Intelligent Primitive Driver should be applied to other JAUS compliant

platforms and further application testing should be performed. In doing this, the viability

of the component could be completely explored and documented. After this, the

component could be presented to the Working Group of the Joint Architecture for

Autonomous Systems (JAUS) for the formal inclusion of the IPD into the Reference

Architecture.


















APPENDIX A
STANDARD JAUS MESSAGES

This Appendix contains information pertaining to the "Set Wrench Effort" and

"Query Global Pose" standard JAUS messages, as well as a list of the core JAUS

message set.

A.1 Query Global Pose

The command code for this message is defined as 0x2402 and causes the receiving

component to respond with a "Report Global Pose" message. Table A-i depicts the data

field assignments for the "Query Global Pose" message [10].



Table A-i: "Query Global Pose" data field (used from JAUS: Reference Architecture
Specification, pg. 93)
Field # Name Type Units Interpretation
Presence Unsigned A See Report Global Pose
Vector Short Message





A.2 Set Wrench Effort

The command code for this message is defined as 0x0405 and controls platform

mobility actuators by mapping the six propulsive and six resistive elements that comprise

a wrench command to the mobility actuators of a vehicle. Table A-2 depicts the data

field assignments for the "Set Wrench Effort" message [10].














Table A-2: "Set Wrench Effort" data fields (from JAUS: Reference Architecture
Specification, pg. 80)
Field # Name Type Units Interpre


1 Presence Vector


2 Propulsive Linear
Effort X
3 Propulsive Linear
Effort Y
Propulsive Linear
Effort Z
5 Propulsive Rotational
Effort X
6 Propulsive Rotational
Effort Y
7 Propulsive Rotational
Effort Z
Resistive Linear
Effort X
Resistive Linear
Effort Y
Resistive Linear
Effort Z
Resistive Rotational
Effort X
Resistive Rotational
12
Effort Y
Resistive Rotational
13fort
Effort Z


Unsigned Short








Short Integer














Byte


N/A








Percent














Percent


See mapping
table that
follows.


Scaled Integer
Lower Limit
=-100
Upper Limit
= 100










Scaled Integer
Lower Limit
=0
Upper Limit
= 100


Vector to Data Field Mapping for Above Command
15 14 13 12 11 10 9
R R R R 13 12 11
7 6 5 4 3 2 1
9 8 7 6 5 4 3
"R" indicates that the bit is reserved.


station


Vector Bit
Data Field
Vector Bit
Data Field


0
2









A.3 JAUS Core Message Set

Table A-3 shows the core set of JAUS messages and their corresponding command

codes [10].


Table A-3: JAUS core message set
Code
Ox01 Set Component A1
0x02 Shutdown
0x03 Standby
0x04 Resume
0x05 Reset
0x06 Set Emergency
0x07 Clear Emergency
0x08 Create Service Co
0x09 Confirm Service C
OxOA Activate Service C
OxOB Suspend Service C
OxOC Terminate Service
OxOD Request Compone
OxOE Release Compone
OxOF Confirm Compon
Ox10 Reject Componenl


Description
authority







nnection
connection
connection
connection
Connection
nt Control
nt Control
ent Control
t Control















APPENDIX B
STAIR COUNTER MATHEMATICAL DEVELOPMENT

The ability to count the number of steps the Andros has passed is critical to the ability

of the Intelligent Primitive Driver to perform its designed task. As discussed in Chapter

3, the current location on the stairs of the Andros is used to trigger controlled events

during the stair climbing procedure. To ensure that this was done as accurately as

possible, the optimum deployment angle for the infrared sensors needed to be determined

so that the stair peaks and their corresponding second derivative impulses were easily

observable by the system.



Y


Sensor Line of Action

offset
/7 I --X


Figure B-l: Stair representation


~ u









The stair representation used for this development has been drawn relative to the

plane of motion of the Andros, as shown in Figure B-1. This reference frame is

appropriate as the sensor array moves along a path parallel to the plane of motion of the

Andros and the measured distances are relative to this plane, and not to the ground plane.

The single stair representation shown is defined by its rise, run, and the angle, P, which is

determined through basic geometry and is constructed of two lines that are perpendicular

to each other at their single point of intersection. As the stair representation is

constructed of two linear equations, one for the rise and one for the run, two separate

equations for the distance, d, must be developed. The distance, d, is the range distance

measured from the infrared sensor to the profile of the stair.


Y





(xo,yo) a (xy)






j-X
"__ _ x


Stair Runner


Figure B-2: Stair runner model


1









Figure B-2 shows the model used for the development of the equation for the

distance, d, as it applies to runner of the stair. The first step in determining d is to find

the point of intersection between the stair runner linear equation and the line of action of

the sensor, (xo, yo). As the y-axis component of this point is constrained to be at yo, xo

can easily be found by solving the equation of the line. Using this as the point of origin,

the distance, a, can be found to the point (x,y), which corresponds to the current location

of the sensor. This distance is given as:

a = (xo x) + (yo y) (B-l)

Now that the distance, a, has been acquired, the perpendicular distance, f, can be found

by the equation:

f = a sinf (B-2)

Through the similar triangles concept, the angle, P, is shown on the two locations of

Figure B-2. The angle, y, is the user-defined angle of the infrared sensor. Therefore, the

intermediate angle, r, may be found, which then leads to the angle, d, by the equation:

0 = 90 7 P (B-3)

The distance, d, is now simply:


Cd O (B-4)


Figure B-3 shows the model used for the development of the equation for the

distance, d, as it applies to riser of the stair. Again, the first step is to find the point of

intersection, (xo, yo), between the stair riser linear equation and the line of action of the

sensor. Again, as the y-axis value is constrained to be yo, xo can be found by solving the






67


equation of the line. Using this as the point of origin, the distance, a, can be found to the

point (x,y), which corresponds to the current location of the sensor.



(x,y) a -


XX
Y




d


SStair Riser



Figure B-3: Stair riser model

The equation for this distance is shown in Equation B-1. Through the similar

triangles concept, the angle, 0, is shown on the two locations of Figure B-3. The angle, y,

is the user-defined angle of the infrared sensor. Using y and 0, the angle, T, may now be

found by:

=r-P (B-5)


The distance, f, is defined as:


f = a cos

Finally, the distance, d, may be found by:


d =
COS Z


(B-6)


(B-7)










The two equations for the distance, d, and the stair data representation were placed

into an Excel spreadsheet for analysis. From this, Figure B-4 was obtained. As shown in

the figure, if the user-defined sensor angle, y, is less than 90 degrees relative to the line of

action of the sensors, the stair edge is skewed to the left and the risers are more

pronounced over the range of the stair data. If y is greater than 90 degrees to the line of

action of the sensors, the stair edge is skewed to the right and the runners are more

pronounced over the range of the stair data. Therefore, it was determined that y should be

90 degrees, or perpendicular to the line of action of the sensors, as this case is neutral and

shows no preference to either the risers or to the runners of the stair data. As the stair

edges are more pronounced in the neutral case, so to will the second derivative impulses

be more pronounced and more easily observed by the system.



18

16

14 -

1200

10

8

6

4

2 *y<90
y= 90
0 -7Y>90
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Distance (in)

Figure B-4: Calculated distances, d, for varying value ofy















LIST OF REFERENCES


[1] Bayouth, M., Nourbakhsh, I., and Thorpe, C., "A Hybrid Human-Computer
Autonomous Vehicle Architecture," Third ECPD International Conference on
Advanced Robotics, Intelligent Automation and Control, 1997.

[2] Mustererkennung und Szenenanalyse (MESA) Research Group, 2003, "Semi-
Autonomous Driving: Intelligent Cruise Control," MESA Research Group,
http://www.neuroinformatik.ruhr-
unibochum.de/PROJECTS/PATREC/projects/DAS/sadicc/sadicc d.html, Feb
2003.

[3] Schlegel, N.,1997, "Autonomous Vehicle Control Using Image Processing,"
Virginia Polytechnic Institute and State University,
http://scholar.lib.vt.edu/theses/public/ etd-283421290973280/etd.pdf, Feb 2003.

[4] Connell, J. and Viola, P., "Cooperative Control of a Semi-Autonomous Mobile
Robot," Proc. of the 1990 IEEE International Conf. on Robotics and Automation
(ICRA-90), 1990, pp. 1118-1121.

[5] Huntsberger, T., and Rose, J., "Behavior-based control for autonomous mobile
robots," ROBOTICS2000, Albuquerque, NM, Mar 2000, pp. 299-305.

[6] Matthies, L., Xiong, Y., Hogg, R., Zhu, D., Rankin, A., Kennedy, B., Hebert, M.,
Maclachlan, R., Won, C., Frost, T., Sukhatme, G., McHenry, M., and Goldberg,
S., "A Portable, Autonomous, Urban Reconnaissance Robot," The 6th
International Conference on Intelligent Autonomous Systems, Venice, Italy, July
2000.

[7] Lewis, M., and Simo', L."Certain Principles of Biomorphic Robots,"
Autonomous Robots, volume 11, 2001, pp. 221-226.

[8] Talebi, S., M. Buehler, M., and Papadopoulos, E., "Towards Dynamic Step
Climbing for a Quadruped Robot with Compliant Legs," Proceedings of the 3rd
International Conference on Climbing and Walking Robots, Madrid, Spain,
October 2000.

[9] Lauria, M., Piguet, Y. and Siegwart, R. "Octopus An Autonomous Wheeled
Climbing Robot," In Proceedings of the Fifth International Conference on
Climbing and Walking Robots. Published by Professional Engineering Publishing
Limited, Bury St Edmunds and London, UK, 2002.






70


[10] JAUS Working Group, 2002, "Joint Architecture for Unmanned Systems (JAUS):
Reference Architecture Specification", Version 3.0, Volume 2, The Joint
Architecture for Unmanned Systems, http://www.jaugs.org, Feb 2003.

[11] Operations and Maintenance Manual for Andros Mark VI Robot System,
Remotec, Inc., Oak Ridge, TN., (2001).

[12] Bock, R., 1998, "The Data Analysis BriefBook: Median Filter,"
Forschungszentrum Juelich, http://ikpell01.ikp.kfa-
juelich.de/briefbook data analysis/nodel68.html, June 2003.

[13] Tanaka, K., An Introduction to Fuzzy Logic for Practical Applications, Springer,
New York, New York, (1997).















BIOGRAPHICAL SKETCH

Peter M. Vinch, Jr. was born on October 29, 1976 in Lawrenceville, New Jersey to

Peter and Nancy Vinch, Sr. He received his Bachelor of Science degree in mechanical

engineering, graduating with honors, from the Rochester Institute of Technology in May

of 2000. In August of 2000, he enrolled at the University of Florida and entered the

master's program in the Department of Mechanical and Aerospace Engineering. Upon

graduation from the University of Florida, he plans to work in the area of autonomous

vehicle development.











University of Florida Graduate School
Electronic Thesis and Dissertation (ETD) Rights
and Permission

1. Enter and submit on line. 2. Print, sign, and submit to Graduate School Editorial Office

Student Name: Peter M. Vinch, Jr.

ID#: 6566-1370

Document Type: V Master's Thesis Doctoral Dissertation

Document Title: Design and Implementation of an Intelligent Primitive Driver


Student Agreement:


I hereby certify that I have obtained all necessary permission in writing for copyrighted material to be published in my
thesis or dissertation. Further, I certify that I have obtained and attached hereto a written permission statement from the
owners) of any copyrighted matter to be included in my thesis or dissertation, allowing distribution as specified below.
Copies of all such permissions are maintained in my files.

I hereby grant to the University of Florida and its employees the nonexclusive license to archive and make accessible,
under the conditions specified below, my thesis or dissertation in whole or in part in all forms of media, now or
hereafter known. This is a license rather than assignments, and I, therefore, retain all other ownership rights to the
copyright of the thesis or dissertation. I also retain the right to use in future works (such as articles or books) all or part
of this thesis or dissertation.

In addition to the unrestricted display of the bibliographic information and the abstract, I agree that the above
mentioned document be placed in the ETD archive with the following status (choose one of 1,2, or 3) by checking the
appropriate space below):
1 1. Release the entire work immediately for access worldwide.
S2. Restrict access to the entire work to the University of Florida and all patrons of its libraries, including
interlibrary sharing and release of doctoral dissertations to UMI. [Please check appropriate time span.]
After (_1, 2, 3, 4, 5, _10) years release my work worldwide unless you receive in writing a request
from me to continue restricted access. If I choose to release the work for worldwide access sooner, I will
contact Library Archives, P.O. Box 117007, University of Florida, Gainesville, FL 32611.
S3. Secure the entire work for patent and/or proprietary purposes for a period of six months. During this period the
copyright owner also agrees not to exercise her/his ownership rights, including public use in works, without
prior authorization from the University of Florida. At the end of the six-month period, either I or the
University of Florida may request an extension for an additional six months. At the end of the six-month
secure period (or its extension, if such is requested), the work will be handled under option 1 above, unless I
request option 2 in writing.

The undersigned agrees to abide by the statements above, and agrees that this approval form updates any and all
previous approval forms submitted heretofore.

Signed:
(Student) (Date)


(Chair)


(Date)










University of Florida Graduate School
Electronic Thesis and Dissertation (ETD) Signature Page


Student's Name: Peter M. Vinch, Jr.

This document has been reviewed and accepted by the student's supervisory committee.


Professor's name & title including department Professor's signature


Name Carl D. Crane, III I Chair
Title Professor of Mechanical and Aerospace Engineering


Name John K. Schueller
Title Professor of Mechanical and Aerospace Engineering


Name Eric M. Schwartz a
Title Lecturer of Electrical and Computer Engineering


Name
Title


Name
Title


Name
Title

Name

Title

Month and Year of Graduation: August 2003


College Dean:
(when required by college)
Name
Title
Graduate Dean:

You do not provide this signature. The
Editorial Office will ask the Graduate School
Dean to sign it later, after commencement.