DESIGN AND IMPLEMENTATIONOF A LUNABOT

SYSTEMS ENGINEERING PAPER

THIRD ANNUAL LUNABOTICS MINING COMPETITION

MAY 21 - 26 2012

Carlos Francisco Rodriguez | Nicolas Ochoa | Juan Pablo Barreto | Antonio Garcia

Andres Latorre | Sebastian Macias | Fabio Lopez | Sebastian Ruiz | Santiago Grass  Ramiro Montufar | Juan Felipe Moreno | Camilo Acosta | Juan Sebastian Velandia  Christian Meneses| Franz Mojica | Camila Gonzalez | Luis Linares | Alvaro Gonzalez  Alejandro Montoya | Daniel Rodriguez | Sergio Bacca | John Estupiñan | Carlos Roso  Jorge Garzon | Juan Camilo Machado | Andres Diaz | Sergio Andres Moreno Tellez

“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard.”

John F. Kennedy

2

I. INTRODUCTION

This document illustrates the design, construc-tion, verification, and validation process of Robo-col’s Lunabot, for Lunabotics Mining Competition2012 (LMC). First, as a requirement for the compe-tition it documents the ideas, projections, decisions,and implementations, under systems engineeringguidelines [1]. It is also intended to be a referencedocument for future participations from Universidadde Los Andes into such competitions.

There are two major expectations within the de-velopment of a lunabotics Project hosted by NASA.Promote the development of interest in space activ-ities and STEM (Science, Technology, Engineering,and Mathematics), and focus this interest in a novelapproach for tackling complex technical challengesthat has gained popularity in recent years. Throughthis, a sponsoring company holds a contest in whicha similar challenge is proposed, resulting in inter-esting concepts that could actually function underreal conditions.

Fuel and oxygen are two imperative needs forhuman manned missions on the moon, and fur-thermore for coming lunar stations. Particularly inthis project, the challenge of designing, buildingand testing a robot, which its main objective is toexcavate and transport lunar regolith is a priorityfor mentioned activities on the moon. Basically be-cause evidence shows that lunar soil has significantamount of both oxygen [2] and fuel [3].

As the main feature for Lunabotics Mining com-petition, Robocols participating Lunabot up to dateis presented in Figure 1, being the team conceptualsolution for the problem stated above. The followingsections describe the design fabrication and verifi-cation process to achieve this robot.

Fig. 1. Robocol’s lunabot up to date

A. General Problem Identification2012 general rules and rubrics document written

by NASA for LMC [4], describe the lunabot as ateleoperated or autonomous robot, with the follow-ing constraints:

• Maximum mass and volume specified.• Capacity of excavating, transporting, and de-

positing at least 10 kg of lunar simulant overa specified area in less than 10 minutes.

• Operating principles restricted only to thoseplausible on the moon.

• Communications must be configured on Wi-Fistandards.

B. Specific problem identificationAdditional, and specific requirements are identi-

fied from abstracting the main objective into majorsystems identified in Figure 2.

Fig. 2. Identified systems of the lunabot

Each system has a set of requirements, and theyare shown in Figure 3 and 4.

Fig. 3. Mechanical systems requirements

Fig. 4. Electric and Electronic systems requirements

II. MANAGEMENT AND PROJECT DEVELOPMENT

The following section describes managementtools used in the project to advice and supportadequately the development of each phase.

3

A. Group OrganizationFor 2011-2012, 11 mechanical engineers, 9 elec-

tronic engineers, 2 industrial engineers and 1 graph-ical designer composed Robocol team. As part ofthe planning strategy, the team structure was settleddown and the team was divided into two majorstrategic units: Mechanical Unit and ElectronicsUnit, both being helped by an extra Support Unit.

This unit was commissioned of obtaining, plan-ning and managing resources, schedule fulfillment,and finally, give extra support on different categoriesrelated with the contest such as Outreach Project,Systems Engineering Paper, Slide Presentation andTeam Spirit. The group organization is shown inFigure 5.

Once the organization chart was specified, teamgeneral objectives and those related to each hier-archical level (Robocol, Areas, Sub-systems andIndividuals) were defined. Those objectives were theinput for a central control panel including deadlinesand indicators for each one, created to assess theconsecution of them and to organize the projectdevelopment process. This central control panelwas transformed into the project’s schedule andits objectives, with deadlines, jobs distribution andbudget. Figure 6. shows the Gantt diagram for 2011-2012 project.

Fig. 6. Gantt diagram for 2011-2012 project

B. BudgetAn objective budget was specified to each area

and each sub-system had an economical constraint.

This economic restriction was given to each leaderof the small groups. Planning the budget for LMC2012 had last year’s expense record as an input,adjusting the amount of money with variations onprices and currency rate. In order to save money,robot must be part of traveller’s luggage, instead ofbe shipped to KSC. This is one an important reasonto decide that the robot had to be modular. Figure 7shows the target budget for each area, includingOutreach Project and Team Spirit categories.

Fig. 7. Target Budget for the Project

III. PHASE A

A. Formulation

On 2011 edition, 5 mechanical engineers and1 electronic engineer formed the team. They hada good performance in the competition, placing20th within 36 teams in the Joe Cosmo award ofexcellence without scoring in mining category. Theyachieved good scores in the Outreach Project andthe Slide Presentation. Being a small group withmajor mechanical emphasis had as a consequenceon the development of the project some issuesdue to the lack of work force in electronics area.For 2012, with the deep desire of improving 2011representation, Robocol did some scouting labor,

4

Fig. 5. Group Organization

re-structured the team, and a strategic plan wasdeveloped, as shown above.

A remarkable fact that influences the project forphase A is that its starting point is located onthe Lunabot presented for LMC 2011. Objectivesproposed in phase A, came out partially from an-alyzing 2011 Lunabot performance, strengths andweaknesses.

B. Background

Figure 8 shows the Lunabot presented for 2011LMC, two separated vehicles composed the Lun-abot, the first one, was indtended to excavate andthe other one, to transport. This robot lied on theidea that a quick transportation needs lightweighthardware. On the other hand, a massive excava-tion demands big and robust structures. In orderto gain the advantages of a quick transportation,and abundant excavated mass, two vehicles, eachone with demanded characteristics to comply quicktransportation, and high excavation rates was pre-sented.

1) Changes from last year competition: Oneenormous difference between 2012 and 2011 LMCis the scoring system established for mining cat-egory. A main consequence is that the excavatedmass is no longer the only variable which evaluatesrobot’s performance. In order to establish the mainobjectives according to scoring system, a sensibilityanalysis was executed.

As a conclusion, according to the scoring systemand technical difficulty, the team priorities are: Tobuild a lunabot as light as possible, which mustexcavate 10 kg of regolith, with at least partial

Fig. 8. 2011 Robocol’s Lunabot

autonomy. The second level of priority would be:Improving excavated mass above 10 kg, and provideprotection for dust tolerant operation. A third level isstated as full autonomy, energy consumption report,and low data transmission.

In Table I, it is clearly demonstrated, how signif-icant the lunabot’s mass becomes, being five timesmore important than excavated mass. Acknowledg-ing this fact, Robocol’s team objective is to builda robot that is able to overpass -300 lunapoints,considering its weight and the excavated mass.

TABLE ISCORE COMPARISONS

Robot Robot Excavated Mass Scoremass (kg) mass (kg)

2011 winner 80 237 -326Equivalent prototype 30 10 (minimum) -300

Having that in mind, first approximation to sys-

5

tems was done

C. Excavation

From last year’s participation, a bucket chain sys-tem was 2011-2012 starting point. System’s height,wasted energy (by rising regolith to over 130cm)and loss of regolith were their main problems. Thisyear, the system chosen had to avoid, at least, men-tioned conditions, increasing efficiency. The require-ment of lightweight mechanism was included. Twosolutions were proposed for this system, a screwconveyor [5] and a bucket with a ramp [6]. Theprototypes that were tested are shown in Figures 9.

(a) Screw conveyor (b) bucket wheel

Fig. 9. Excavation prototypes

The main results for the tests performed onexcavation prototypes are shown in Figure 10 andFigures 11

Fig. 10. Screw excavated mass, test of 10s

The bucket wheel achieves a better excavationrate of 80g/s vs. 60g/s of the screw conveyor.

According to specified requirements, an evalua-tion comparing performance criteria was held, andit is shown in Table II.

As can be seen in Table II, the best option forthe excavation system is the bucket wheel and rampsystem, it is the starting point for the final systemdesign.

Fig. 11. Bucket wheel excavated mass, test of 30s

TABLE IIEXCAVATION SYSTEMS COMPARISON

System Screw Bucketconveyor wheel and ramp

Height (20%) 3 7Power demand (10%) 4 6Regolith loses (20%) 8 5Excavation rate (25%) 4 7Weight (25%) 2 7Weighted score 4,1 6,5

D. Traction

A 4×4 differential traction system was the lastyear’s Lunabot driving system. Even if it had agood speed, its ability to turn was not as desired.The system for this year had to be as quick andlightweight as the 4×4 system, but it had to ensure agood maneuverability. Two solutions were proposedas well; an ackerman steering mechanism [7], anda vehicle driven by crawlers [8]. Figure 12 showsthe tested prototypes.

(a) Ackerman steering mecha-nism

(b) Crawlers prototype

Fig. 12. Traction prototypes

The main results for the tests performed areshown in Figure 13 and Figure 14.

As can be seen in the graphs, the Ackermansteering mechanism has a lower power demand; itis also lighter than crawlers, which penalizes thepower consumption comparison. A first impression

6

Fig. 13. Ackerman steering mechanism power consumption

Fig. 14. Crawlers power consumption

would be that this system is more adequate than thecrawlers; nevertheless structural integrity, stability,and the ability to support other structures makethe crawlers a better choice. As well as with theexcavation systems, the performance criteria areevaluated as follows in Table III.

TABLE IIITRACTION SYSTEMS EVALUATION

System Ackerman CrawlerManeuverability (25%) 10 9Weight (25%) 8 6Power demand (10%) 6 6Speed (15%) 7 10Stability (25%) 4 9Weighted score 7,15 8,1

E. Discharge

Regarding the discharge system, a great uncer-tainty was present in the rest angle of the regolithduring 2011 competition. This implied overdesignedslopes in the containers or discharge mechanisms,and the use of vibrators for improved sliding of theregolith. A rigorous study on regolith properties wasperformed to reduce the uncertainty present in 2011Lunabot.

1) Regolith Analysis: As explained above it isimportant to understand regolith behavior to reduce

uncertainty on robot’s operation. A BP-1 sampleform 2011 competition was obtained for this pur-pose.

In order to simulate BP-1 to run tests for thisyear’s competition, a granulometry test was per-formed. According to what is suggested by standardASTM D422-63, a hydrometer test and a sievingone were executed to determine the particle sizedistribution of the sample. Even if a large amountof BP-1’s particles distribution are smaller than75 µm, simulate this part of the distribution isreally difficult, so they are taken away from analysisunder the assumption that macroscopic propertiesare not significantly dependent on particles smallerthan 75 µm. Figure 15 shows the size distributionobtained for BP-1.

Fig. 15. BP-1 particle size distribution

Having this distribution was the first step of thesimulation process, then, a batch around 200kgof mining material available in civil engineeringlaboratory was taken and sieved with the same threesieves ran on the test before, separating the materialin desired sizes. Finally, mixing different particlesizes according to proportion shown in table, shouldbe enough to have own BP-1 simulant.

The amount created seemed enough to understandBP-1 behavior in storage and discharge system butit is not enough to test mining or transport systems.At this time evaluations are held to determine if itis worthy to continue creating BP-1 simulant to testall Lunabot’s systems.

2) Container and lifting mechanism: Acknowl-edging that the container in which regolith must bedeposited is over 50 cm the probability of needing alifting mechanism is high if a stable robot is desired.Mechanisms used in 2011 proved being reliable,lightweight and demanded acceptable power levels.

7

For this reason the scissors mechanism is highlyrecommended for this purpose, including the linearactuators used in last yeas competition.

By the other hand, size and shape of a provisionalcontainer were designed and built. Container was re-stricted to a volume of 80cm × 16cm × 40cm. Dueto the lifting system, a rectangle shaped containerwas not the best choice; a high angle on the dis-charge side was needed to ensure that all the regolithexcavated would be able to leave the container.Kinematic analysis (and further test) proved that, ifthe container started in horizontal position, scissorssystem achieved an inclination angle of 25◦, whichdid not seem enough to ensure desired condition.The inclination angle was improved on 27◦ and theshape shown in Figure 16 was decided.

Fig. 16. discharge system comparisons

Figure 16 shows a pivoted system (left) and arailed system (right), comparison of systems resultsin qualification shown in Table IV.

TABLE IVDISCHARGE MECHANISMS COMPARISON

System Pivoted RailsDeployment angle 17◦ 38◦

Return to original position Yes NoDust affectation No YesWeight 40g 150gRegolith wasted during unload None Nono

F. Control and Data ProcessingFor last years competition, the central controller

was implemented with a dsPIC33FJ64MC508 microcontroller from Microchip. As the 2012 competitionrequires more data processing due to the establishedtarget of enabling autonomous or semi-autonomousoperation the Lunabot, a more powerful central con-troller was required. Thus, two ideas were proposed:Using an industrial embedded computer (Advan-tech PCM-3363D-1GS8A1E) or a netbook (ToshibaNB255). Both options were analyzed, as it is shownin Table V.

TABLE VCONTROL SYSTEMS COMPARISON

Device PC 104 NetbookProcessor 10 10

Weight 10 7Memory 8 9Storage 9 10

Ports 10 9Power Supply 3 8

Total 9.27 8.67

Based on the score obtained by each device, theembedded computer (also know as the PC-104) waschosen as the best option, and the netbook remainedas backup. However, while testing the PC-104, ashort circuit through its power circuitry affectedseriously the device disabling it. Due to the timingand budget constraints of the project, and since thescore for both options was close, it was decidedto use the Netbook as the central controller andprocessing unit in the Lunabot.

In order to perform Input/Output operations be-tween the computer and the hardware of the Lunabot(i.e. H-bridge drivers for the motors, the relay boardfor the linear actuators, the distance sensors, etc.)there needs to be an interface to synthesize therequired analog and digital signals. For prototyp-ing purposes a dsPIC30F4011 microcontroller wasused for PWM signal generation, and concurrentlyan ATxmega32A4 for acquisition of the distancesensors (Sharp IR optopairs) and of the end stopswitches. However, we decided to migrate devel-opment to the Arduino platform, employing twoArduino Mega boards (one for motor control and theother for control of actuators and acquisition of sen-sors). This choice was effected because the Arduinoplatform reduces the time of program/upload/testiterations in the prototyping cycle. The Arduinoplatform is an open source project for fast proto-typing of electronic systems. It embodies an AVRATmega microcontroller at its core, and an USB-serial interface which simplifies communicationswith the microcontroller, both for code uploadingand information transmission from and to the mi-crocontroller.

In the control and data processing system,thealgorithms for autonomy were considered as well.To achieve the autonomous and semiautonomousoperation three main goals were identified:

1) Identify obstacles and planes

8

2) Identify a fixed Beacon3) Determine a navigation path through the

Lunarena.

Two options were considered to accomplish theidentification of obstacles and planes: training aneural-fuzzy network or a Supported Vector Ma-chine with images taken from a real environmentwith obstacles, and random sampling and consensus(RANSAC) segmentation of planes in 3D. Becausethe testing error for the first option was around 30%,the second option was selected for its better results.For the identification of the Beacon, three optionswere considered for its definition:

• A magnetometer• A source infrared light• Image Analysis.

The first option was discarded because external in-terference could impact the system in a considerablyadverse way. Also, the second option was discardedbecause of the complexity in making a reliableinfrared source. Thus, the third option was selected.

Finally, for the navigation algorithm three optionswere considered Quadrant Navigation, Bug2 andSlam. The Table VI summarizes the comparisonmade among the three algorithm strategies.

TABLE VIALGORITHM COMPARISON

Algorithm QuadrantNavigation

Bug2 SLAM

Processing Time 9 6 3Computational Cost 8 6 3Localization precision 5 6 10Robot movement complexity 10 4 3Total 8,1 5,5 4,8

Certainly the SLAM algorithm is very strongfor localization and mapping, but it demands ahigh computational cost and processing time, whichmakes it unsuitable for the Lunabotics competitionconsidering the time limit and the required preci-sion. This is so because it is not fundamental tomap precisely the LunArena, but to travel quicklythroughout it so as to maximize the quantity ofexcavated regolith). For this reason, and consideringTable VI, the selected algorithm for the autonomousoperation of the robot is the Quadrant Navigationstrategy.

G. Power and Energy supply

This subsystem involves three main tasks: First,the design and implementation of the circuitry topower and allow the control of the traction and thedigging motor. Second, the design and implementa-tion of the circuitry to power and allow the controlof the linear actuators. Thrid, the supply of energyto all the circuitry, motors and linear actuators inthe robot.

1) Motors: The design and implementation ofthe circuitry to power the motors was consideredone of the most critical tasks due to the expe-rience during the competition last year. On thatoccasion, the electronic system failed because thedesign implemented a poor level of voltage isolationbetween the digital control and the power deliverysub-circuits. Thus, this issue became of paramountimportance for our participation in this year, andso special focus was given on the handling of thecurrent spikes in the motors produced by the PWMpower delivery topology by which they are driven.

The first design approach for the power modulewas to develop our own H-Bridge implementationusing discrete components. Even though the imple-mentation was successful and we were able to movethe lunabot, both the power and energy efficien-cies were deemed too low, hence establishing therejection of this alternative. This fact was revealedduring testing, also finding that the maximum outputcurrent of the H-Bridge for reliable operation was10 A, due to the thermoelectric characteristics ofthe available commercial references of its switchingcomponents. The following references were usedfor the tests: TIP31 (Power BJT), IRG4PC50UD(IGBT) and IRFZ44N (MOSFET) . The designoptions listed below summarize the team’s effortsin this regard:

• Option A: An H bridge and a driver imple-mented with discrete components available inthe local market in Colombia. There were sev-eral topologies tested using different solid statedevices, such as IGBTs, MOSFETs and BJTs.

• Option B: A fully integrated monolithic H-Bridge motor driver (VNH3ASP30Both options were implemented and tested, andthe results are presented in Table VII, alongwith the characteristic of each option. As canbe noted, the winner is option B.

9

TABLE VIIH BRIDGE COMPARISON

Option Option A Option BAvailability of components (20%) 10 5

Solution simplicity (10%) 4 10Performance (50%) 8 10

Power dissipation (20%) 7 10Total 7,8 9

2) Actuators: For the circuitry to power thelinear actuators, the use of relays [9] wasconsidered, based on the experience of lastyears competition. The objective of the relays isto bias the actuators with an apparent voltage+24 V to stretch them up and -24V to makethem contract. This solution worked correctlyduring its initial tests and no other solutionswere considered, due to the low level of controlresolution demanded for their operation.3) Batteries and Power Supply: For the energysupply, the experience from the last year’s com-petition showed that Li-Po batteries offer thebest energy-mass ratio and had an acceptablecost as compared to the other options consid-ered. Based on that experience, the first con-templated option was to use 5 Ah @ 22.2 V Li-Po batteries and employ DC-DC converters tosupply the electronic circuitry with 5V or 3.3Vas required by each component; to supply theactuators at battery voltage, and to use DC-DCconverters to supply the traction and excavationmotors with 12V. However, after acquiring 12Vmotors, measurements taken when testing themrevealed a high current demand during theiroperation. This made the team estimate moreconvenient to acquire 12V LiPo batteries formotor supply and to use the existing 24Vbattery for the two linear actuators.

H. Sensing

The sensing subsystem was partitioned basedon the principal functions to be provided,which are three as follows: First, the detectionof holes and obstacles. Second, the detectionof regolith mass in the container. Third, imageacquisition1) Detection of hole and obstacles in theLunarena: As for the first alternative, capaci-tive and inductive sensors were evaluated. Theywere discarded because their operating speci-

fications targeted for industrial settings makethem unsuitable for integration within the Lun-abot. In the case of second alternative, infrareddistance sensors were considered. After analyz-ing most of the locally available commercialsensors, the GP2Y0A02YK [10] sensor fromSharp was selected, due to its considerabledistance sensing range (30 150 cm) and itslow energy consumption (165 mW @ 5 V). Inaddition , because the calibration curve followsa simple inversely proportional relation to thesensed distance, the data acquisition of thesesensors is easy.

TABLE VIIIDETECTION SENSOR COMPARISON

Sensor Capacitive SharpInductive

Energy Supply (30%) 5 10Computational complexity (10%) 5 10Sensing distance (50%) 3 7Price (10%) 3 6Total 3.3 8.1

2) Detection of regolith mass in the container:As the first alternative it was considered tolocate infrared sensors inside the container todetermine the height of the recollected regolith;however, because of the semi-random variationin the shape of the surface of the accumulatedregolith in the container, the sensed distanceis not an adequate estimator. Hence it wasdecided to use limit switches to mark a set ofdiscrete levels of container filling.

TABLE IXDETECTION OF REGOLITH MASS SENSOR COMPARISON

Sensor Limit Switch SharpEnergy Supply 10 4Processing Simplicity 10 6Sensed distance 10 2Dust tolerance 7 4Total 8.8 3.7

3) Images acquisition: There is a variety ofavailable technologies for imaging sensing, thatwere evaluated as shown in Table XBy assigning more weight to the 3D capa-bilities cost features, it was decided to use aKinect Sensor as the main device for imagesacquisition, and a simple Web Camera as anauxiliary sensor.

10

TABLE XIMAGES ACQUISITION COMPARISON

Sensor type Cost 3D Image Computational Totalcapabilities capabilities complexity

Simple RGB camera 10 2 5 1 4,2Stereo (dual) RGB camera 2 7 7 5 5,4Laser range-finder 1 10 1 10 5,5IR + RGB pair (Microsoft Kinect) 7 5 5 7 6

I. CommunicationsThe Communication area involves the imple-mentation of a user interface to remotely op-erate the Lunabot from a Control Computer;the implementation of a script to handle thedata flow transmitted and received between theControl Computers wireless adapter and theLunabot; and the use of a wireless device inthe Lunabot to transmit and receive the data.For the last years competition a LantronixMatchPort b/g embedded wireless server wasused in the Lunabot to enable transparent serialcommunications between the central controllerand the computer, over a WiFi channel. How-ever, the choice of a Netbook as the centralcontroller of the Lunabot made unnecessary theLantronix device because of the netbooks built-in wireless adapter. The connection betweenthe lunabot computer was initially going to bethrough RS-232 interfaces over standard DB-9 connectors, as the PC-104 has two RS-232serial interfaces available. After replacing thePC-104 with the netbook, no RS-232 interfaceswere available and the communication channelwas changed to USB-CDC (emulation of aserial channel over USB). The lack of a fourthUSB port in the netbook, as required by theamount of USB devices to be connected, madethe acquisition of an USB Hub necessary.Concerning the implementation of the userinterface and the script for the data flow han-dling, it was decided to use Python 2.7 as thelanguage, due to its unique mix of features: it isopen source, as interpreted language it obviatesprogram compilation, it has an ample codebaseof libraries and extensions, and a large, activecommunity.

J. Budget revisionExpenses of Phase A were around 1550 USD,corresponding to 54.5% of initial budget pro-

posed for that phase. The fact that some of theprototypes and studies were done under aca-demic subjects taken by team students meansthat the project, receives a mandatory budgetaccording to university rules. This is the reasonwhy the difference in some cases is elevated.Nevertheless, the team does not count withthe remaining money to afford next Phaseexpenses; it has to be returned to sponsors(University). Detailed values of expenses andbudget for this phase are shown in Figure17.

Fig. 17. Budget summary phase A

1) Chronogram Revision: Electronics area hada good performance in terms of following theschedule, the communications study had noproblem, but power circuit study faced minortroubles related with the implementation ofits PCB system. The mechanical area accom-plished the schedule for the majority of thestudies, except for a delay on the dischargesystem due to the high time requirements ofthe sieving process.

IV. PHASE BOnce the conceptual solutions were selected,the next step in the design process was todevelop hierarchy relations between those sys-tems, in order to provide the first structure tothe final design. The hierarchical diagrams forthe hole robot, mechanical systems, and elec-tronics systems are shown first in this section,followed by the final design, final designs pereach system and interfaces that arose betweenthem.

11

A. Hierarchy of designed SystemsFigure 18 shows the hierarchy established forthe mechanical systems. In it, the first level isrecognized as the structure or chassis, everyother part or mechanism is attached to it, orto other systems that are joined to the chassis.Then, in the second level the traction systemand the lifting system are allocated becauseonce they are joined to the structure, theyperform their functions. On the third level thereis located the excavation and discharge systembecause they perform their function only whenthey are joined to the lifting system.

Fig. 18. Hierarchy of mechanical systems

Once the hierarchy diagram has been devel-oped for mechanical and electronic systems,Figure 19 presents de hierarchy diagram for thewhole robot taking into account all systems.The control system receives commands fromthe user through the communication subsystem.It then transforms these commands into digitalsignals to move the motors and the actua-tors and send them to the power subsystem.Also, the control receives the data sensed fromthe sensing subsystem, processes it, and sendsthese data to the control computer if it isrequested.The diagram Shown in Figure ??fg: fig20e)details a description of the electronic system.As shown, the Netbook sends and receivesdirectly the signals from the user interface.It also receives the images from the WebCamera and the Kinect sensor. In addition,two Arduinos are used for the Control and

Processing System. One of them is used tosend PWM signals, through the H-Bridge, tothe traction and excavation motors; also it isused to process the motors current sensed bythe H-Bridges as well as the motors positionas marked by the encoders. The other Arduinois used to send control signals to the linearActuators through the relays control circuitry;It is also used to process the signals from theSharp IR Sensors and from the limit switchsensors.

B. Critical designAs expected, the traction system is the base ofthe Lunabot, a chassis is assembled to supportthe lifting and turning systems designed for theexcavation and discharge process. However, theelectronics integration is more comprehensibleanalyzing its block diagram than seeing theintegrated Lunabot. Integration of the Lunabotis done in this way because it is designed as amodular system. One of the principal reasonsof the modular design is to ensure an easy wayto transport (or ship) it to the Kennedy SpaceCenter.

Fig. 20. Mechanical integrated system

A modular design was selected to assemblyall the electronic systems. The motherboard isthe main PCB designed to interconnect eachof the PCBs that conform the whole electronicsystem. This board is the biggest one shown in

12

Fig. 19. Block diagram

the Figure 22. There are six PCBs connectedto the motherboard: Three H-Bridge boards,two Arduino boards and a drive system for thelinear actuators based in relays.

Fig. 21. Designed Motherboard PCB

Fig. 22. Implemented Motherboard PCB along with the Kinect,WebCam and Netbook

The considerable amount of connectionsamong the different circuit boards that are partof the final robot prompted us to create amotherboard that routes most of those connec-tions. We developed component libraries on thesoftware Eagle PCB Designer and design thefinal PCBs around the EDGE AMP connec-tors. Due to the high currents that each motorrequire (up to 30 A, in stall rotor condition), themotherboard PCB was designed to have shortand wide traces on which the current from thebatteries to the motor go through. The widthof these traces on the PCB was oversized, asalso were the cables that go from the threeH-Bridges to their corresponding motors, as asafety factor.

C. Interfaces

1) Mechanical interfaces: Besides bolts andscrews employed to assemble the systems,there are more mechanical elements that canbe considered as interface.2) Electronic interfaces: In Table XII the in-terfaces between electronics subsystem andsystems are presented.3) Global interfaces: Global interfaces referto interfaces between mechanical and electrical

13

TABLE XIIELECTRONIC INTERFACES

Elements Systems interacting TypeSubsystem USB A/B Cable Arduino and Netbook (Control and Processing) Structural

System 50-pin EDGE AMP Connector, motherboard H-Bridge (Power) , StructuralArduino (Control and Processing)

System 50-pin EDGE AMP Connector, motherboard Arduino (Control and Processing), StructuralSharp IR and line switch sensors (Sensing)

System 50-pin EDGE AMP Connector, motherboard Relays (Power), StructuralArduino (Control and Processing)

System USB A/B Cable Cameras (Sensing), StructuralNetbook (Control and processing)

System Python Script Control and Processing, Comunication FunctionalSystem Python Script Control and Processing, Comunication FunctionalExternal Graphical User Interface (GUI) and Joystick Comunication, Functional

User

TABLE XIMECHANICAL INTERFACES

Elements System interacting TypeSubsystem Shaft Wheel, screw, chain Functional

Chain Shaft, motor Power transmissionCrawler, motor

Bearings Shaft, structure StructuralSystem Chassis Traction, scissors Structural

Scissors Chassis, excavation FunctionalExternal Belt Lunabot, soil Functional

Bucket Lunabot, soil Functional

systems. Basically, wires which dispositionsare shown in the Figure 23 compose the in-terfaces.

Fig. 23. Global interfaces

D. Final designs per system

System described in previous phase were se-lected to be implemented in the Lunabot, itsfinal design is described as follows:1) Traction system: Two modular crawlerscompose traction system chosen. Each crawlerhas its own aluminum structure where motorand rollers are assembled. The triangular shapeof the structure allows the motor to be far fromtraction area, reducing its failure by crash prob-ability. Due to this separation, a chain-sprocketsystem is used to power transmission with arelation of 2:1, increasing systems speed. Asshows Figure 24, rollers are placed along thestructure to ensure the tension in belt neededto be functional.

Fig. 24. Traction system.

Due to the modular integration, a motoris needed per crawler. Motor selection wasdone according to dynamic simulation results(loaded container) and market availability. Mo-tors selected have a torque of 21.09 N.m. statedon datasheet.

14

2) Excavation system: Three subsystems com-pose the Lunabots excavation system: a bucket-wheel, an Archimedes screw, an U-shapedcanal with its corresponding drive shaft (withits sprocket), its distribution is shown in Fig-ure 25.

Fig. 25. Excavation system

The bucket wheel is composed by a 48cmdiameter support were 20 buckets are assembly.Once the wheel is turning, excavated soil fallsinto the canal and is transported by the screwto the container.Selection of the motor for this system is sup-ported by similarity laws analysis done with asmaller bucket wheel. The result of the analysisshows that the motor selected for the tractionsystem has enough torque to excavate the BP-1.3) Discharge system: As shown in Figure 26the discharge system is a passive door pivotedsystem, This system is composed by a con-tainer (72cm × 23cm × 15cm) and a smallsheet (20cm) assembled by a hinge joint. A lift-ing system was required too, it was designed tolift and turn the container in order to guaranteethe correct discharge of regolith.

Fig. 26. Discharge system.

Nevertheless, the shape of the container and itsturning were not enough to guarantee this pro-

cess, an additional metal sheet was assembledwith a hinge.

4) Control and data processing: The Lun-abots central controller (the netbook) receivesthe signals from the Mission Control computer(located outside the Lunarena) via WiFi, pro-cesses them, and finally sends the appropriatesignals to the corresponding Arduino board tocontrol the motors, the linear actuators or to ac-quire information like the sensed distances, therecollected regolith amount or the actual powerconsumption. If the user sets the autonomousoperation of the Lunabot, the signals to controlthe motors and linear actuators are determinedby a set of algorithms.The Operating System (OS) running on thenetbook is Ubuntu 11.10 Server Edition. Thereason for this choice is that this edition istailored for standalone, console operation, andso lacks a graphical user interface (GUI). AGUI is not needed on this computer given thatit is going to be on the robot at all times. Todispense with a GUI also allows the auton-omy algorithms to use all computing resourcesavailable.The human interface for tele-operation of theLunabot is a PlayStation 3 Controller driven bya GUI that also shows the sensor measurementsand the images from the cameras onboard. Allof the software on the Lunabot computer waswritten in C++ and Python 2.7, and the soft-ware running on the Mission Control computerwas developed on Python 2.7 using differentlibraries such as QT for the User Interface andTornado for the Web Server.On the subject of autonomy, there are two tasksto perform: Spatial awareness and Goal steer-ing. Spatial awareness is concerned with local-ization of the Lunabot relative to the Lunarena,so that it can effectively know whether therobot is in the start area, obstacle area, andmining area. Goal steering is the algorithmicstrategy to position the robot and to have itexecute the actions required at every stage ofthe competition attempt. The spatial awarenesscomputing pipeline is partitioned into the sub-tasks listed below

– Segmentation of planes and identificationof non-planar objects.

15

– Registration of the beacon located at oneof the Lunarena’s walls.

– Positioning with respect to this beacon

Fig. 27. Designed Beacon

The algorithm summaries for the Registrationof the Beacon is shown in Figure 30 andfor planes segmentation and non-planar objectidentification is shown in Figure 29.

Fig. 28. Algorithm for the identification of the beacon

The selected algorithm strategy for Goal Steer-ing is Quadrant Navigation, which consists ofdividing the bounded map of the Lunarena intosquares of the same size as the robots maxi-mum dimension, making the representation ofthe map as a matrix for the robot, and navigatesadvancing through these quadrants avoiding theobstacles, moving forward, backward, right andleft. For the robot return to the starting position,the route that was taken to arrive to the miningarea is saved in the robots memory so that therobot can return through that safe route.5) Power and energy supply: For the powerhandling of the motors the monolithic H-bridgeVNH3ASP30 it was used. This device handlesa maximum of 30A of continuous current. ThisIC consists in a full bridge motor driver whichincorporates dual monolithic High-Side drivers

Fig. 29. Algorithm for planes and objects identification

and two Low-Side switches with their asso-ciated protection circuitry. It also implementsmonitoring of the load current.As the devices silicon is packaged in a SurfaceMount package, it was needed to design andfabricate PCBs to use and test it. Two PCBswere designed for the usage of this H-Bridge.The first one was design just to test the func-tionality of the H-Bridge coupled to an Arduinoboard. With this test we noted that not all ofthe required digital signals from the H-Bridgewere needed at all, with some of them neverchanging their logic state. The second PCBdesigned was adapted to the AMP EDGE con-nection, and included identified enhancementswith respect to power dissipation and currentsteering, among other aspects.

Fig. 30. Second PCB designed for the H-Bridge

Regarding the energy supply, given that the

16

motor power consumption on the robot isaround 360 W, worst case scenario, and 72W for each linear actuator, we oversized thebatteries needed for the robot. We calculatedthe number of batteries that go on the robotso as to enable a Lunabot runtime of up to 25minutes. That is 150% more that the actual du-ration of a competition attempt. The calculationyielded six 6.4 Ah @ 12 V Li-Po batteries tosupply all the motors and one 5 Ah @ 22.2V Li-Po battery to supply the linear actuators.The electronic circuitry is supplied by the USBports of the netbook, and a 9V battery is usedas a backup for the two Arduino boards.6) Sensing: There are 12 different sensorslocated on the LunaBot: Five distance sensorslocated at the left, right, front and back sideof the lunabot to measure the distance fromthe lunarena walls or obstacles to the Lunabot.The sensors are located as shown in the imagebelow. Two sensors were placed at the backof the robot due to the high accuracy neededto park it in front of the Lunarenas regolithdeposition bin.

Fig. 31. Distance sensors location

There are 3 limit switches located at the Re-golith container as shown below, to measure theamount of recollected regolith. These sensorswere located according to the distribution ofthe regolith inside the box, so that it can beknown when the excavation must be stoppedand/or when 10 Kg have been excavated. Theselimit switches are processed using the ArduinoButton library [11].There are also 4 limit switches to monitor theactuators position. Finally, there is a Kinectsensor located at the front of the Lunabot andthere is a web cam, to acquire images from thesurroundings of the Lunabot.

Fig. 32. limit switches location

7) Communications: The application of thenetbook as the processing and control unit inthe Lunabot implies the use of a client-servermodel between the Mission Control computerand the netbook. Because of this, two Pythonscripts were implemented: one for the server(i.e. netbook) and other for the client (MissionControl computer). Both scripts use the nativePython library Socket for handling the commu-nication between the two computers over WiFi.The router that links the two computers wasconfigured so that the assigned IP address tothe computers remains fixed, by setting upDHCP reservation for their individual MACaddresses.At the control computer there is a script thatsets up a GUI and enables a PlayStation 3Controller to control the excavation and trac-tion motors as well as the linear actuators.The GUI provides a user-friendly environmentthat displays the data sensed at the Lunabotand the current through the motors. It alsoimplements control of the motors and the linearactuators from the keyboard as a backup, incase the PlayStation 3 Controller fails. Sincethe Lunabot has the option to be autonomous,the implementation of a tele-operated modecovers us in case the autonomy fails. From theGUI the user will be able to choose amongautonomous or tele-operated modes.A communication protocol was developed be-tween the netbook and the Arduino boards.Since there are two of them and it is not knownbeforehand which port the OS assigns to them,a handshaking protocol was implemented inwhich the computer sends the ? symbol andthe Arduino returns and M if it is the Arduinowho controls the motors or and S in case itis the Arduino who controls the actuators andsensors. By this means the computer identifies

17

which Arduino is in which port and can routethe correct commands to each.Regarding the communication between the twocomputers in the Lunabot and Mission Control(server and client computers, respectively), thefollowing setup is built. At the beginning thecomputer on the robot (server) accepts clientson the port 3000. But in case this port isblocked by another program, the server pro-gram continues to listen on the subsequentports up to port 3100. On the other hand,the client starts by requesting a connection onthe port 3000 but in case this fails, the clientproceeds to request connection on the nextports up to the port 3100.The client and server computers acknowledgeeach other in a similar way the Lunabot com-puter identifies the Arduino boards attached toit. This is accomplished by a handshaking eventin which, after accepting the connection, theserver sends the string Hello? and the clientreplies with Hi. Afterwards the server needsto authenticate the client, by parsing the username and a password sent by the client. Theresult of this simple authentication procedureyields an approval or denial message. Whenthe user is approved, the client is able to sendthe commands to the Lunabot.The communication protocol was designed toconsume the least amount of bandwith thatwas practical. Most of the commands consistof a single byte, with some exceptions. Themessages that consume the most bandwidth arereply messages from the server. This messagesgive feedback of the status of the robot. Thereis a provision in the clients GUI to disable thesemessages.For the image transfer a small web server wascreated on the netbook. The language used forthis was Python 2.7 using the Tornado library.The capture of the cameras was made with theOpenCV implementation for Python.

E. Contingency identification and risk analysis

Contingencies were identified in every systemand solutions were proposed to reduce the riskof each one. The results for mechanical andelectronics systems are shown in tables XIIIand XIV

TABLE XIIICONTINGENCY ANALYSIS FOR MECHANICAL SYSTEMS

Trouble Risk SolutionTraction Stacked/buried

crawler++ Brooms in the side of

crawlers.Jammingcrawler

- Path on rollers

Excavation Bucker fracture - Backup bucketsDisplacementsof elements inshaft

++ Seeger rings.

Chassis and Structuralfatigue

++ Change material.

elevation Weld failure + Backup criticalelements.

Discharge BP1 excavatedexceeds dimen-sions of pivotedsheet

++ Enlarge lateral sheets.

All systems Wear dueto dustinterference

+++ Acrylic protectionsfor chain paths,small pores bags formotors and electronicscontainer, plastic tubesfor actuators, brushesfor crawlers

F. Budget revisionAt this point, 55% of the budget for Phase Bhas been spent. Troubles caused by supplierdelays generated some over costs, in specificareas, but they were covered by the expectedbudget. Apparently, the project will be com-pleted without exceeding the budget. Detailedvalues for each area and manufacturing labora-tory services are shown in Figure 33.

Fig. 33. Budget revision phase B

G. Chronogram revisionRegarding mechanical systems, the majorityof the sub-systems accomplished the deliverydates, except for the container and the dis-charge system, due to the delay that occurredon previous phase, which had an impact of 6weeks.The groups associated with crawlers and struc-ture finished their tasks in the estimated timeand did not face any significant trouble. On theother hand, electronics had some complications

18

TABLE XIVCONTINGENCY ANALYSIS FOR ELECTRONICS SYSTEMS

Trouble Risk SolutionCommunication Loss of

communicationbetween Clientand Server

+ Handshaking betweenClient and Servers.

Blocked Port - Define alternative portsPower High current

levels+++ Widen traces on PCBs

Current Spikes ++ Improve the Soft Startstrategy.

Induction ofhigh currentsinto digitalcircuits

++ Use of low currentfuses in digitalcircuitry. Insulatedgrounds for power anddigital circuits.

Failure of therelay - basedcontrol PCBfor the linearactuators

+++ Continuousreplacement of theULN2003 powerdriver.

Sensing Limit SwitchWear

++ Use high quality limitSwitch and replacethem continuously.

Robot vibrationcould affectthe SharpIR sensors,causing poorperformance

+ Implement a best me-chanical holder for thesensors or filter data viasoftware.

Intense lightingaffects the per-formance of theKinect

+ Kinect Calibration un-der different lightingcondition.

Control PC heatingcould causepossible shutdown due tohigh processorusage inautonomyalgorithmsand signalprocessing.

– Design a PC coolingcontrol system usinglow power fans.

with autonomy system, basically caused by thedelay on the rest of sub-systems.The only sub-system that got the job done ontime was sensors. At the time that all the sub-systems should be presented on its 100%, thereal performance was as follow: sensors 100%,communication 70%, power transmission 80%and autonomy 40%. Nevertheless, power trans-mission was finished two weeks later and com-munications system was accomplished threeweeks later than expected.

V. PHASE C

A. Test Design

Some tests have to be designed. Test run haveto ensure that system chosen accomplishes allthe requirements stated. In the same way, thetest will be an important tool to improve theintegrated system.1) Mechanical tests: Tests were designed forall system separately. Each one of the testsis shown as a table with parameters relevantto the feature to characterize, some of themare settled constant, others are variables. Thetraction test is intended to characterize its force.The power consumption of this system can alsobe determined from this test.

TABLE XVTRACTION TEST DESIGN

Parameter LevelsVertical Load (Kg) 10, 20, 30, 40

Speed (m/s) 0,43Contact Area (cm2) 500

Width (cm) 70Rotation Angle (◦) 0,45,90,180

Linear distance (m) 10

The test shown in table XV validates all trac-tion requirements stated before.The discharge test is intended to characterizethe amount of regolith dumped out of theLunabin.

TABLE XVIDISCHARGE TEST DESIGN

Parameter LevelsMass (kg) 10,15,20,25

Distance (cm) 40, 50, 60Discharge angle (◦) 60

Pivoted sheet length (cm) 20Pivoted sheet deployment (◦) 17

Rising velocity (cm/s) 3,1

Accurate values for distance parking and un-derstand of the behavior of BP-1 during thedischarge process are the intended results fromthis test.The excavation test is intended to characterizethe excavation rate of the system.From this test, an optimization of the excava-tion rate is desired. An acknowledge of the BP-1 behaviour during the excavation period is alsointended.

19

TABLE XVIIEXCAVATION TEST DESIGN

Parameter LevelsDiameter (cm) 48

Width (cm) 10Buckets (amount) 20

Forward,Crawler’s path backward,

spinning.Motors voltage (◦/s) 8, 10, 12

Structural test is intended to validate the struc-tural integrity and to find the best performancefor the chassis and the scissor lift mechanism,when the other systems are assembled to it.

TABLE XVIIISTRUCTURAL TEST DESIGN

Parameter LevelsMass in container [Kg] 10, 15, 20, 25

Voltage [V] 12, 24Height [m] 1,5

Actuator stroke [m] Stroke endNumber of continuous cycles 5

2) Electronics test: The H-Bridge was testedwith a PWM with a frequency of 3.9K froman Arduino. At first, the correct operation ofthe H-Bridge was tested and the results arepresented in Table XIX

TABLE XIXMAXIMUM VALUES OF INPUT AND OUTPUT VOLTAGES IN THE

H-BRIDGES

Enable A Enable B Output A Output B0 5 0 125 0 12 05 5 12 12

After verifying the correct operation of all theH-Bridges, the motors were connected underdifferent conditions and powered using the H-Bridge. Each test and the result are presentedin Table XX.

TABLE XXH-BRIDGES TESTED USING THE MOTORS UNDER DIFFERENT

CONDITIONS

Test ResultClockwise whirl with no load 100%Counter- clockwise whirl with no load 100%Clockwise whirl with 58kg load 100%Counter-clockwise whirl with 58kg load 100%

Once it was implemented the whole designedmentioned before, the teleoperated control of

the robot was tested. The main data obtainedfrom this test was the bandwidth consumedwhen receiving and sending data from and tothe robot. The following data was collectedfrom these tests using the software Wiresharkfor Linux.

TABLE XXIBANDWIDTH CONSUMPTION TEST

Test Level (Mb/s)Robot movement commands BW 0,15Webcam images BW 1,56 Mb/sKinect images BW 2,2 Mb/sTotal BW 3,91 Mb/s

In order to test the IR sensors that were goingto be located in the Lunabot (front, back, left,right), a small prototype of the robot wasdesigned and all the 5 sensors were placedon it. The Sharp IR sensors were connectedto an Arduino MEGA and then the followingdata was recovered from several analysis re-garding some key features needed for the finalimplementation. The calibration curve was theninverted and linearized so it could be used aproportional relation between sensed distanceand output.

TABLE XXIIIR SENSORS TEST

Parameter LevelsMinimum sensing distance (cm) 23Maximum sensing distance (cm) 110Dissipation current (mA) 27Ambient light tolerance YesOutput voltage with a 5V power supply (V) 0,5 - 4,8

Its not worth mentioning the results obtainedwhen the tests with the limit switches weredone. This is because these switches doesntpresent an appreciable power dissipation norany other key feature for its implementation.3) General test: Finally, a test for the in-tegrated system was designed. Conditions ofLunabotics Mining Competition were simu-lated for the global test, the robot was intendedto make the same process as in competitionattempt, and requirements tested are shown inTable XXIV.None of the tests explained before have beenrun rigorously, dates for each one are estimatedand stated on table XXV.

20

TABLE XXIIIGENERAL TEST

Trouble CorrectionMechanical Roller stocked be-

cause of regolith.Screw path on theroller.

Wasted regoliththrough the wheel.

Canal enlarged

Bearing damage dueto regolith.

Bearing support re-oriented

Discharge out oflunabot.

Parkingimprovement

Electronical WebCam distortiondue to regolith

Improve the digitalfilter

Kinect Distortiondue to regolith

Add a new Digitalfilter

Over Heating inelectronics

Include a fan

TABLE XXIVREQUIREMENTS CHECKED IN GENERAL TEST

Parameter RequirementAutonomy Yes/Not

Loaded straight movement (>10 kg) Yes/NotStructural failure Yes/Not

Lost communication Yes/NotLoaded maneuverability (>10 kg) Yes/Not

Minimum Excavation (>10kg) Yes/NotTravel time (min) <3

Excavation time (min) <5Discharge time (min) <1

Power supply time (min) >15

TABLE XXVESTIMATED DATES FOR TESTS.

Test DateMechanical Traction 23-Apr

Discharge 24-AprExcavation 24-Apr

Chassis 25-AprScissors 25-Apr

Electrical H-BRIDGES 26 - AprBandwidth consumption 30 - Apr

IR Sensors 27 - AprAutonomy 2 - May

General 04-may

B. Corrections

Even if the rigorous test have not been runyet, operation approximations have been done,setting bases for small system corrections.

C. Budget revision phase C

Even if Phase C is not over yet, some prelimi-nary tests have been run and some correctionswere needed. The purchase of material used forcorrections has spent 35.62% of the budget forPhase C. Figure 34 shows budget expenses for

this phase

Fig. 34. Budget expenses for phase c

D. Chronogram RevisionEven though the group had some delays inphases A and B, the project is actually on a80% of its development. According to sched-ule, the only job that has not started yet is thetest of the integrated systems (mechanical andelectronic). Some tasks exceeded its plannedtime but others were before planned, at thispoint, few tasks remain undone.

VI. CONCLUSIONS

A. Budget conclusionsAt this point, 80% of the project is completedand around 55% of the budget has been spent.Nevertheless, expensive purchases and serviceswill be needed in the remaining tests andcorrections.A projection of the future expenses predictsthat the project will spend around 94% of thetarget budget, as shows Figure 35. To conclude,the budget stated was enough to cover allphases expected during the project.

Fig. 35. Budget expenses

B. General conclusionsSystem engineering guidelines were followedto accomplish a Lunabot’s design process,according to requirements stated by NASA.Thanks to their experience, last year partici-pants involved in the team enriched the entireprocess, their problems and success from lastyear were the starting point for many of thesystems tested and selected this year.The structured process over the last 9 monthsinvolved not only team members but also a

21

lot of people through academic courses in theUniversidad de los Andes. This cooperationallowed them to participate in Phase A, byproposing their own ideas, producing proto-types and learning from robotics principles andhelped Robocol to decide its final design.At this point, Robocols Lunabot is almostfinished, some corrections need to be done tostart final tests and finish validation process.Since the entire process was done rigorously,good results are expected in LMC 2012, inwhich excavating and depositing at least 10 kgof regolith during official attempt sessions isexpected.

REFERENCES

[1] NASA, Ed., NASA Systems Engineering Handbook.NASA, 1995.

[2] U. Wiechert, A. Halliday, D. Lee, G. Snyder, L. Taylor,and D. Rumble, “Oxygen isotopes and the moon-forminggiant impact.” Science, vol. 294, no. 5541, pp. 345–8,2001.

[3] J. K. G. Wittenberg, L.J.; Santarius, “Lunar source of/sup 3/he for commercial fusion power,” Fusion Technol,vol. 10:2, pp. 167–178, 1986.

[4] N. Aeronautics and S. Administration, “NASA’s ThirdAnnual Lunabotics Mining Competition Rules andRubrics and Rubrics,” January 2012.

[5] H. Omori, T. Nakamura, T. Yada, T. Murakami,H. Nagai, and T. Kubota, “Excavation mechanismfor a planetary underground explorer robot.” inISR/ROBOTIK. VDE Verlag, 2010, pp. 1–7.[Online]. Available: http://dblp.uni-trier.de/db/conf/isr/isr2010.html#OmoriNYMNK10

[6] L. Rasper, The Bucket Wheel Excavator: Devel-opment, Design, Application, ser. Series on BulkMaterials Handling. Trans Tech Publications, 1975.[Online]. Available: http://books.google.com.co/books?id=IkJkQgAACAAJ

[7] R. Norton, Design of Machinery: An Introductionto the Synthesis and Analysis of Mechanisms andMachines, ser. Engineering Series. McGraw-Hill HigherEducation, 2003. [Online]. Available: http://books.google.com.co/books?id=LLWBbV5 hF0C

[8] G. Ishigami, A. Miwa, K. Nagatani, and K. Yoshida,“Terramechanics-based model for steering maneuver ofplanetary exploration rovers on loose soil: Researcharticles,” J. Field Robot., vol. 24, no. 3, pp. 233–250,Mar. 2007. [Online]. Available: http://dx.doi.org/10.1002/rob.v24:3

[9] Z. Z. T. Co., “T73(jqc-3ff) relay.” [Online]. Available:http://www.relays-china.com/t73(jqc-3ff)-relay.html

[10] SHARP, “Long distance mesuring sen-sor igp2y0a02yk datasheet.” [Online]. Avail-able: http://sharp-world.com/products/device/lineup/data/pdf/datasheet/gp2y0a02 e.pdf

[11] A. Brevig, “Button library for arduino,” 05 2009.[Online]. Available: http://arduino.cc/playground/Code/Button