Systems Engineerig Paper - Robocol Uniandes 2012

“ Wec hoos et og ot ot hemooni nt hi sde c a de a nddot heot he rt hi ng s , notbe c a us et he ya r e e a s y , butbe c a us et he ya r eha r d. ” J ohnF. Ke nne dy

DESI GNANDI MPLEMENTATI ON OFALUNABOT SYSTEMS ENGI NEERI NG PAPER

THI RDANNUALLUNABOTI CSMI NI NGCOMPETI TI ON MAY21-26 201 2

Carl osFranc i s c oRodri guez| Ni c ol asOc hoa| J uanPabl oBarreto| Antoni oGarc i a AndresLat orre| Sebast i anMac i as| Fabi oLopez|

Sebast i anRui z| Sant i agoGrass Rami roMont uf ar|

J uanFel i peMoreno| Cami l oAc ost a|

J uanSebast i anVel andi a Chri st i anMeneses|

FranzMoj i c a| Cami l aGonzal ez|

Lui sLi nares|

Al varoGonzal ez Al ej androMont oy a|

Dani elRodri guez| Sergi oBac c a|

J ohnEst upi ñan|

Carl osRoso J orgeGarzon|

J uanCami l oMac hado|

AndresDi az|

Sergi oAndresMorenoTel l ez

2

I. I NTRODUCTION This document illustrates the design, construction, verification, and validation process of Robocol’s Lunabot, for Lunabotics Mining Competition 2012 (LMC). First, as a requirement for the competition it documents the ideas, projections, decisions, and implementations, under systems engineering guidelines [1]. It is also intended to be a reference document for future participations from Universidad de Los Andes into such competitions.

There are two major expectations within the development of a lunabotics Project hosted by NASA. Promote the development of interest in space activities and STEM (Science, Technology, Engineering, and Mathematics), and focus this interest in a novel approach for tackling complex technical challenges that has gained popularity in recent years. Through this, a sponsoring company holds a contest in which a similar challenge is proposed, resulting in interesting concepts that could actually function under real conditions.

Fuel and oxygen are two imperative needs for human manned missions on the moon, and furthermore for coming lunar stations. Particularly in this project, the challenge of designing, building and testing a robot, which its main objective is to excavate and transport lunar regolith is a priority for mentioned activities on the moon. Basically because evidence shows that lunar soil has significant amount of both oxygen [2] and fuel [3].

As the main feature for Lunabotics Mining competition, Robocols participating Lunabot up to date is presented in Figure 1, being the team conceptual solution for the problem stated above. The following sections describe the design fabrication and verification process to achieve this robot.

Fig. 1.

Robocol’s lunabot up to date

A. General Problem Identification 2012 general rules and rubrics document written

by NASA for LMC [4], describe the lunabot as a teleoperated or autonomous robot, with the following constraints: • Maximum mass and volume specified.

• Capacity of excavating, transporting, and depositing at least 10 kg of lunar simulant over a specified area in less than 10 minutes.

• Operating principles restricted only to those plausible on the moon.

• Communications must be configured on Wi-Fi standards.

B. Specific problem identification Additional, and specific requirements are identified from abstracting the main objective into major systems identified in Figure 2.

Fig. 2.

Identified systems of the lunabot

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

Fig. 3.

Mechanical systems requirements

Fig. 4.

Electric and Electronic systems requirements

II. M ANAGEMENT AND PROJECT DEVELOPMENT The following section describes management tools used in the project to advice and support adequately the development of each phase.

3

A. Group Organization For 2011-2012, 11 mechanical engineers, 9 electronic engineers, 2 industrial engineers and 1 graphical designer composed Robocol team. As part of the planning strategy, the team structure was settled down and the team was divided into two major strategic units: Mechanical Unit and Electronics Unit, both being helped by an extra Support Unit.

This unit was commissioned of obtaining, planning and managing resources, schedule fulfillment, and finally, give extra support on different categories related with the contest such as Outreach Project, Systems Engineering Paper, Slide Presentation and Team Spirit. The group organization is shown in Figure 5.

Once the organization chart was specified, team general objectives and those related to each hierarchical level (Robocol, Areas, Sub-systems and Individuals) were defined. Those objectives were the input for a central control panel including deadlines and indicators for each one, created to assess the consecution of them and to organize the project development process. This central control panel was transformed into the project’s schedule and its objectives, with deadlines, jobs distribution and budget. Figure 6. shows the Gantt diagram for 20112012 project.

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

Fig. 7.

Target Budget for the Project

III. P HASE A A. Formulation On 2011 edition, 5 mechanical engineers and 1 electronic engineer formed the team. They had a good performance in the competition, placing 20th within 36 teams in the Joe Cosmo award of excellence without scoring in mining category. They achieved good scores in the Outreach Project and Fig. 6. Gantt diagram for 2011-2012 project the Slide Presentation. Being a small group with major mechanical emphasis had as a consequence on the development of the project some issues B. Budget due to the lack of work force in electronics area.

An objective budget was specified to each area For 2012, with the deep desire of improving 2011 and each sub-system had an economical constraint. representation, Robocol did some scouting labor,

4

Fig. 5.

Group Organization

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

A remarkable fact that influences the project for phase A is that its starting point is located on the Lunabot presented for LMC 2011. Objectives proposed in phase A, came out partially from analyzing 2011 Lunabot performance, strengths and weaknesses.

B. Background Figure 8 shows the Lunabot presented for 2011 LMC, two separated vehicles composed the Lunabot, the first one, was indtended to excavate and the other one, to transport. This robot lied on the idea that a quick transportation needs lightweight hardware. On the other hand, a massive excavation demands big and robust structures. In order to gain the advantages of a quick transportation, and abundant excavated mass, two vehicles, each one with demanded characteristics to comply quick transportation, and high excavation rates was presented.

1) Changes from last year competition: One enormous difference between 2012 and 2011 LMC is the scoring system established for mining category. A main consequence is that the excavated mass is no longer the only variable which evaluates robot’s performance. In order to establish the main objectives according to scoring system, a sensibility analysis was executed.

As a conclusion, according to the scoring system and technical difficulty, the team priorities are: To build a lunabot as light as possible, which must excavate 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 provide protection for dust tolerant operation. A third level is stated as full autonomy, energy consumption report, and low data transmission.

In Table I, it is clearly demonstrated, how significant the lunabot’s mass becomes, being five times more important than excavated mass. Acknowledging this fact, Robocol’s team objective is to build a robot that is able to overpass -300 lunapoints, considering its weight and the excavated mass.

TABLE I S CORE COMPARISONS Robot 2011 winner Equivalent prototype

Robot mass (kg) 80 30

Excavated mass (kg) 237 10 (minimum)

Mass Score -326 -300

Having that in mind, first approximation to sys-

5

tems was done C. Excavation From last year’s participation, a bucket chain system was 2011-2012 starting point. System’s height, wasted energy (by rising regolith to over 130cm) and loss of regolith were their main problems. This year, the system chosen had to avoid, at least, mentioned conditions, increasing efficiency. The requirement of lightweight mechanism was included. Two solutions were proposed for this system, a screw conveyor [5] and a bucket with a ramp [6]. The prototypes that were tested are shown in Figures 9.

Fig. 11.

Bucket wheel excavated mass, test of 30s TABLE II E XCAVATION SYSTEMS COMPARISON

System Height (20%) Power demand (10%) Regolith loses (20%) Excavation rate (25%) Weight (25%) Weighted score

Screw conveyor 3 4 8 4 2 4,1

Bucket wheel and ramp 7 6 5 7 7 6,5

D. Traction A 4×4 differential traction system was the last year’s Lunabot driving system. Even if it had a (a) Screw conveyor (b) bucket wheel good speed, its ability to turn was not as desired.

Fig. 9. Excavation prototypes The system for this year had to be as quick and lightweight as the 4×4 system, but it had to ensure a The main results for the tests performed on good maneuverability. Two solutions were proposed excavation prototypes are shown in Figure 10 and as well; an ackerman steering mechanism [7], and Figures 11 a vehicle driven by crawlers [8]. Figure 12 shows the tested prototypes.

Fig. 10.

Screw excavated mass, test of 10s

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

According to specified requirements, an evaluation comparing performance criteria was held, and it is shown in Table II. As can be seen in Table II, the best option for the excavation system is the bucket wheel and ramp system, it is the starting point for the final system design.

(a) Ackerman steering mechanism Fig. 12.

(b) Crawlers prototype

Traction prototypes

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

As can be seen in the graphs, the Ackerman steering mechanism has a lower power demand; it is also lighter than crawlers, which penalizes the power consumption comparison. A first impression

6

Fig. 13.

Ackerman steering mechanism power consumption

Fig. 14.

Crawlers power consumption

uncertainty on robot’s operation. A BP-1 sample form 2011 competition was obtained for this purpose.

In order to simulate BP-1 to run tests for this year’s competition, a granulometry test was performed. According to what is suggested by standard ASTM D422-63, a hydrometer test and a sieving one were executed to determine the particle size distribution of the sample. Even if a large amount of BP-1’s particles distribution are smaller than 75 µm, simulate this part of the distribution is really difficult, so they are taken away from analysis under the assumption that macroscopic properties are not significantly dependent on particles smaller than 75 µm. Figure 15 shows the size distribution obtained for BP-1.

would be that this system is more adequate than the crawlers; nevertheless structural integrity, stability, and the ability to support other structures make the crawlers a better choice. As well as with the excavation systems, the performance criteria are evaluated as follows in Table III. TABLE III T RACTION SYSTEMS EVALUATION System Maneuverability (25%) Weight (25%) Power demand (10%) Speed (15%) Stability (25%) Weighted score

Ackerman 10 8 6 7 4 7,15

Crawler 9 6 6 10 9 8,1

E. Discharge Regarding the discharge system, a great uncertainty was present in the rest angle of the regolith during 2011 competition. This implied overdesigned slopes in the containers or discharge mechanisms, and the use of vibrators for improved sliding of the regolith. A rigorous study on regolith properties was performed to reduce the uncertainty present in 2011 Lunabot.

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

Fig. 15.

BP-1 particle size distribution

Having this distribution was the first step of the simulation process, then, a batch around 200kg of mining material available in civil engineering laboratory was taken and sieved with the same three sieves ran on the test before, separating the material in desired sizes. Finally, mixing different particle sizes according to proportion shown in table, should be enough to have own BP-1 simulant.

The amount created seemed enough to understand BP-1 behavior in storage and discharge system but it is not enough to test mining or transport systems.

At this time evaluations are held to determine if it is worthy to continue creating BP-1 simulant to test all Lunabot’s systems.

2) Container and lifting mechanism: Acknowledging that the container in which regolith must be deposited is over 50 cm the probability of needing a lifting 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 highly recommended for this purpose, including the linear actuators used in last yeas competition.

By the other hand, size and shape of a provisional container were designed and built. Container was restricted to a volume of 80cm × 16cm × 40cm. Due to the lifting system, a rectangle shaped container was not the best choice; a high angle on the discharge side was needed to ensure that all the regolith excavated would be able to leave the container.

Kinematic analysis (and further test) proved that, if the container started in horizontal position, scissors system achieved an inclination angle of 25◦ , which did not seem enough to ensure desired condition.

The inclination angle was improved on 27◦ and the shape shown in Figure 16 was decided.

Fig. 16.

discharge system comparisons

Figure 16 shows a pivoted system (left) and a railed system (right), comparison of systems results in qualification shown in Table IV. TABLE IV D ISCHARGE MECHANISMS COMPARISON System Deployment angle Return to original position Dust affectation Weight Regolith wasted during unload

Pivoted 17◦ Yes No 40g None

Rails 38◦ No Yes 150g Nono

F. Control and Data Processing For last years competition, the central controller was implemented with a dsPIC33FJ64MC508 micro controller from Microchip. As the 2012 competition requires more data processing due to the established target of enabling autonomous or semi-autonomous operation the Lunabot, a more powerful central controller was required. Thus, two ideas were proposed: Using an industrial embedded computer (Advantech PCM-3363D-1GS8A1E) or a netbook (Toshiba NB255). Both options were analyzed, as it is shown in Table V.

TABLE V C ONTROL SYSTEMS COMPARISON Device Processor Weight Memory Storage Ports Power Supply Total

PC 104 10 10 8 9 10 3 9.27

Netbook 10 7 9 10 9 8 8.67

Based on the score obtained by each device, the embedded computer (also know as the PC-104) was chosen as the best option, and the netbook remained as backup. However, while testing the PC-104, a short circuit through its power circuitry affected seriously the device disabling it. Due to the timing and budget constraints of the project, and since the score for both options was close, it was decided to use the Netbook as the central controller and processing unit in the Lunabot.

In order to perform Input/Output operations between the computer and the hardware of the Lunabot (i.e. H-bridge drivers for the motors, the relay board for the linear actuators, the distance sensors, etc.) there needs to be an interface to synthesize the required analog and digital signals. For prototyping purposes a dsPIC30F4011 microcontroller was used for PWM signal generation, and concurrently an ATxmega32A4 for acquisition of the distance sensors (Sharp IR optopairs) and of the end stop switches. However, we decided to migrate development to the Arduino platform, employing two Arduino Mega boards (one for motor control and the other for control of actuators and acquisition of sensors). This choice was effected because the Arduino platform reduces the time of program/upload/test iterations in the prototyping cycle. The Arduino platform is an open source project for fast prototyping of electronic systems. It embodies an AVR ATmega microcontroller at its core, and an USBserial interface which simplifies communications with the microcontroller, both for code uploading and information transmission from and to the microcontroller.

In the control and data processing system,the algorithms for autonomy were considered as well.

To achieve the autonomous and semiautonomous operation three main goals were identified: 1) Identify obstacles and planes

8

G. Power and Energy supply 2) Identify a fixed Beacon 3) Determine a navigation path through the This subsystem involves three main tasks: First, Lunarena. the design and implementation of the circuitry to Two options were considered to accomplish the power and allow the control of the traction and the identification of obstacles and planes: training a digging motor. Second, the design and implementaneural-fuzzy network or a Supported Vector Ma- tion of the circuitry to power and allow the control chine with images taken from a real environment of the linear actuators. Thrid, the supply of energy with obstacles, and random sampling and consensus to all the circuitry, motors and linear actuators in (RANSAC) segmentation of planes in 3D. Because the robot. the testing error for the first option was around 30%, 1) Motors: The design and implementation of the second option was selected for its better results. the circuitry to power the motors was considered For the identification of the Beacon, three options one of the most critical tasks due to the expewere considered for its definition: rience during the competition last year. On that • A magnetometer occasion, the electronic system failed because the • A source infrared light design implemented a poor level of voltage isolation • Image Analysis. between the digital control and the power delivery sub-circuits. Thus, this issue became of paramount The first option was discarded because external inimportance for our participation in this year, and terference could impact the system in a considerably so special focus was given on the handling of the adverse way. Also, the second option was discarded current spikes in the motors produced by the PWM because of the complexity in making a reliable power delivery topology by which they are driven. infrared source. Thus, the third option was selected.

The first design approach for the power module Finally, for the navigation algorithm three options was to develop our own H-Bridge implementation were considered Quadrant Navigation, Bug2 and using discrete components. Even though the impleSlam. The Table VI summarizes the comparison mentation was successful and we were able to move made among the three algorithm strategies. the lunabot, both the power and energy efficiencies were deemed too low, hence establishing the TABLE VI rejection of this alternative. This fact was revealed A LGORITHM COMPARISON during testing, also finding that the maximum output Algorithm Quadrant Bug2 SLAM current of the H-Bridge for reliable operation was Navigation 10 A, due to the thermoelectric characteristics of Processing Time 9 6 3 Computational Cost 8 6 3 the available commercial references of its switching Localization precision 5 6 10 components. The following references were used Robot movement complexity 10 4 3 for the tests: TIP31 (Power BJT), IRG4PC50UD Total 8,1 5,5 4,8 (IGBT) and IRFZ44N (MOSFET) . The design options listed below summarize the team’s efforts in this regard: Certainly the SLAM algorithm is very strong for localization and mapping, but it demands a • Option A: An H bridge and a driver implehigh computational cost and processing time, which mented with discrete components available in makes it unsuitable for the Lunabotics competition the local market in Colombia. There were sevconsidering the time limit and the required precieral topologies tested using different solid state sion. This is so because it is not fundamental to devices, such as IGBTs, MOSFETs and BJTs. map precisely the LunArena, but to travel quickly • Option B: A fully integrated monolithic Hthroughout it so as to maximize the quantity of Bridge motor driver (VNH3ASP30 excavated regolith). For this reason, and considering Both options were implemented and tested, and Table VI, the selected algorithm for the autonomous the results are presented in Table VII, along operation of the robot is the Quadrant Navigation with the characteristic of each option. As can strategy. be noted, the winner is option B.

9

TABLE VII H

BRIDGE COMPARISON

Availability of components Solution simplicity Performance Power dissipation

Option (20%) (10%) (50%) (20%) Total

Option A 10 4 8 7 7,8

Option B 5 10 10 10 9

2) Actuators: For the circuitry to power the linear actuators, the use of relays [9] was considered, based on the experience of last years competition. The objective of the relays is to bias the actuators with an apparent voltage +24 V to stretch them up and -24V to make them contract. This solution worked correctly during its initial tests and no other solutions were considered, due to the low level of control resolution demanded for their operation.

3) Batteries and Power Supply: For the energy supply, the experience from the last year’s competition showed that Li-Po batteries offer the best energy-mass ratio and had an acceptable cost as compared to the other options considered. Based on that experience, the first contemplated option was to use 5 Ah @ 22.2 V LiPo batteries and employ DC-DC converters to supply the electronic circuitry with 5V or 3.3V as required by each component; to supply the actuators at battery voltage, and to use DC-DC converters to supply the traction and excavation motors with 12V. However, after acquiring 12V motors, measurements taken when testing them revealed a high current demand during their operation. This made the team estimate more convenient to acquire 12V LiPo batteries for motor supply and to use the existing 24V battery for the two linear actuators.

H. Sensing The sensing subsystem was partitioned based on the principal functions to be provided, which are three as follows: First, the detection of holes and obstacles. Second, the detection of regolith mass in the container. Third, image acquisition 1) Detection of hole and obstacles in the Lunarena: As for the first alternative, capacitive and inductive sensors were evaluated. They were discarded because their operating speci-

fications targeted for industrial settings make them unsuitable for integration within the Lunabot. In the case of second alternative, infrared distance sensors were considered. After analyzing most of the locally available commercial sensors, the GP2Y0A02YK [10] sensor from Sharp was selected, due to its considerable distance sensing range (30 150 cm) and its low energy consumption (165 mW @ 5 V). In addition , because the calibration curve follows a simple inversely proportional relation to the sensed distance, the data acquisition of these sensors is easy.

TABLE VIII D ETECTION S ENSOR COMPARISON Sensor Energy Supply (30%) Computational complexity (10%) Sensing distance (50%) Price (10%) Total

Capacitive Inductive 5 5 3 3 3.3

Sharp 10 10 7 6 8.1

2) Detection of regolith mass in the container: As the first alternative it was considered to locate infrared sensors inside the container to determine the height of the recollected regolith; however, because of the semi-random variation in the shape of the surface of the accumulated regolith in the container, the sensed distance is not an adequate estimator. Hence it was decided to use limit switches to mark a set of discrete levels of container filling.

TABLE IX D ETECTION OF REGOLITH MASS SENSOR COMPARISON Sensor Energy Supply Processing Simplicity Sensed distance Dust tolerance Total

Limit Switch 10 10 10 7 8.8

Sharp 4 6 2 4 3.7

3) Images acquisition: There is a variety of available technologies for imaging sensing, that were evaluated as shown in Table X By assigning more weight to the 3D capabilities cost features, it was decided to use a Kinect Sensor as the main device for images acquisition, and a simple Web Camera as an auxiliary sensor.

10

TABLE X I MAGES ACQUISITION COMPARISON Sensor type Simple RGB camera Stereo (dual) RGB camera Laser range-finder IR + RGB pair (Microsoft Kinect)

Cost 10 2 1 7

3D capabilities 2 7 10 5

I. Communications The Communication area involves the implementation of a user interface to remotely operate the Lunabot from a Control Computer; the implementation of a script to handle the data flow transmitted and received between the Control Computers wireless adapter and the Lunabot; and the use of a wireless device in the Lunabot to transmit and receive the data.

For the last years competition a Lantronix MatchPort b/g embedded wireless server was used in the Lunabot to enable transparent serial communications between the central controller and the computer, over a WiFi channel. However, the choice of a Netbook as the central controller of the Lunabot made unnecessary the Lantronix device because of the netbooks builtin wireless adapter. The connection between the lunabot computer was initially going to be through RS-232 interfaces over standard DB9 connectors, as the PC-104 has two RS-232 serial interfaces available. After replacing the PC-104 with the netbook, no RS-232 interfaces were available and the communication channel was changed to USB-CDC (emulation of a serial channel over USB). The lack of a fourth USB port in the netbook, as required by the amount of USB devices to be connected, made the acquisition of an USB Hub necessary.

Concerning the implementation of the user interface and the script for the data flow handling, it was decided to use Python 2.7 as the language, due to its unique mix of features: it is open source, as interpreted language it obviates program compilation, it has an ample codebase of libraries and extensions, and a large, active community.

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

Image capabilities 5 7 1 5

Computational complexity 1 5 10 7

Total 4,2 5,4 5,5 6

posed for that phase. The fact that some of the prototypes and studies were done under academic subjects taken by team students means that the project, receives a mandatory budget according to university rules. This is the reason why the difference in some cases is elevated.

Nevertheless, the team does not count with the remaining money to afford next Phase expenses; it has to be returned to sponsors (University). Detailed values of expenses and budget for this phase are shown in Figure17.

Fig. 17.

Budget summary phase A

1) Chronogram Revision: Electronics area had a good performance in terms of following the schedule, the communications study had no problem, but power circuit study faced minor troubles related with the implementation of its PCB system. The mechanical area accomplished the schedule for the majority of the studies, except for a delay on the discharge system due to the high time requirements of the sieving process.

IV. P HASE B Once the conceptual solutions were selected, the next step in the design process was to develop hierarchy relations between those systems, in order to provide the first structure to the final design. The hierarchical diagrams for the hole robot, mechanical systems, and electronics systems are shown first in this section, followed by the final design, final designs per each system and interfaces that arose between them.

11

A. Hierarchy of designed Systems Figure 18 shows the hierarchy established for the mechanical systems. In it, the first level is recognized as the structure or chassis, every other part or mechanism is attached to it, or to other systems that are joined to the chassis.

Then, in the second level the traction system and the lifting system are allocated because once they are joined to the structure, they perform their functions. On the third level there is located the excavation and discharge system because they perform their function only when they are joined to the lifting system.

Fig. 18.

Processing System. One of them is used to send PWM signals, through the H-Bridge, to the traction and excavation motors; also it is used to process the motors current sensed by the H-Bridges as well as the motors position as marked by the encoders. The other Arduino is used to send control signals to the linear Actuators through the relays control circuitry; It is also used to process the signals from the Sharp IR Sensors and from the limit switch sensors.

B. Critical design As expected, the traction system is the base of the Lunabot, a chassis is assembled to support the lifting and turning systems designed for the excavation and discharge process. However, the electronics integration is more comprehensible analyzing its block diagram than seeing the integrated Lunabot. Integration of the Lunabot is done in this way because it is designed as a modular system. One of the principal reasons of the modular design is to ensure an easy way to transport (or ship) it to the Kennedy Space Center.

Hierarchy of mechanical systems

Once the hierarchy diagram has been developed for mechanical and electronic systems, Figure 19 presents de hierarchy diagram for the whole robot taking into account all systems.

The control system receives commands from the user through the communication subsystem.

It then transforms these commands into digital signals to move the motors and the actuators and send them to the power subsystem.

Also, the control receives the data sensed from the sensing subsystem, processes it, and sends these data to the control computer if it is requested.

The diagram Shown in Figure ??fg: fig20e) details a description of the electronic system.

As shown, the Netbook sends and receives directly the signals from the user interface.

It also receives the images from the Web Camera and the Kinect sensor. In addition, two Arduinos are used for the Control and

Fig. 20.

Mechanical integrated system

A modular design was selected to assembly all the electronic systems. The motherboard is the main PCB designed to interconnect each of the PCBs that conform the whole electronic system. This board is the biggest one shown in

12

Fig. 19.

Block diagram

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

Fig. 21.

Designed Motherboard PCB

The considerable amount of connections among the different circuit boards that are part of the final robot prompted us to create a motherboard that routes most of those connections. We developed component libraries on the software Eagle PCB Designer and design the final PCBs around the EDGE AMP connectors. Due to the high currents that each motor require (up to 30 A, in stall rotor condition), the motherboard PCB was designed to have short and wide traces on which the current from the batteries to the motor go through. The width of these traces on the PCB was oversized, as also were the cables that go from the three H-Bridges to their corresponding motors, as a safety factor.

C. Interfaces

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

1) Mechanical interfaces: Besides bolts and screws employed to assemble the systems, there are more mechanical elements that can be considered as interface.

2) Electronic interfaces: In Table XII the interfaces between electronics subsystem and systems are presented.

3) Global interfaces: Global interfaces refer to interfaces between mechanical and electrical

13

TABLE XII E LECTRONIC INTERFACES Subsystem System

Elements USB A/B Cable 50-pin EDGE AMP Connector, motherboard

System

50-pin EDGE AMP Connector, motherboard

System

50-pin EDGE AMP Connector, motherboard

System

USB A/B Cable

System System External

Python Script Python Script Graphical User Interface (GUI) and Joystick

Systems interacting Arduino and Netbook (Control and Processing) H-Bridge (Power) , Arduino (Control and Processing) Arduino (Control and Processing), Sharp IR and line switch sensors (Sensing) Relays (Power), Arduino (Control and Processing) Cameras (Sensing), Netbook (Control and processing) Control and Processing, Comunication Control and Processing, Comunication Comunication, User

TABLE XI M ECHANICAL INTERFACES Subsystem

System External

Elements Shaft Chain Bearings Chassis Scissors Belt Bucket

System interacting Wheel, screw, chain Shaft, motor Crawler, motor Shaft, structure Traction, scissors Chassis, excavation Lunabot, soil Lunabot, soil

Type Functional Power transmission

Structural Structural Functional Functional Functional

Structural Structural Functional Functional Functional

System described in previous phase were selected to be implemented in the Lunabot, its final design is described as follows: 1) Traction system: Two modular crawlers compose traction system chosen. Each crawler has its own aluminum structure where motor and rollers are assembled. The triangular shape of the structure allows the motor to be far from traction area, reducing its failure by crash probability. Due to this separation, a chain-sprocket system is used to power transmission with a relation of 2:1, increasing systems speed. As shows Figure 24, rollers are placed along the structure to ensure the tension in belt needed to be functional.

Fig. 24.

Global interfaces

Structural

D. Final designs per system

systems. Basically, wires which dispositions are shown in the Figure 23 compose the interfaces.

Fig. 23.

Type Structural Structural

Traction system.

Due to the modular integration, a motor is needed per crawler. Motor selection was done according to dynamic simulation results (loaded container) and market availability. Motors selected have a torque of 21.09 N.m. stated on datasheet.

14

2) Excavation system: Three subsystems compose the Lunabots excavation system: a bucketwheel, an Archimedes screw, an U-shaped canal with its corresponding drive shaft (with its sprocket), its distribution is shown in Figure 25.

Fig. 25.

Excavation system

The bucket wheel is composed by a 48cm diameter support were 20 buckets are assembly.

Once the wheel is turning, excavated soil falls into the canal and is transported by the screw to the container.

Selection of the motor for this system is supported by similarity laws analysis done with a smaller bucket wheel. The result of the analysis shows that the motor selected for the traction system has enough torque to excavate the BP-1.

3) Discharge system: As shown in Figure 26 the discharge system is a passive door pivoted system, This system is composed by a container (72cm Ă— 23cm Ă— 15cm) and a small sheet (20cm) assembled by a hinge joint. A lifting system was required too, it was designed to lift and turn the container in order to guarantee the correct discharge of regolith.

Fig. 26.

Discharge system.

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

cess, an additional metal sheet was assembled with a hinge.

4) Control and data processing: The Lunabots central controller (the netbook) receives the signals from the Mission Control computer (located outside the Lunarena) via WiFi, processes them, and finally sends the appropriate signals to the corresponding Arduino board to control the motors, the linear actuators or to acquire information like the sensed distances, the recollected regolith amount or the actual power consumption. If the user sets the autonomous operation of the Lunabot, the signals to control the motors and linear actuators are determined by a set of algorithms.

The Operating System (OS) running on the netbook is Ubuntu 11.10 Server Edition. The reason for this choice is that this edition is tailored for standalone, console operation, and so lacks a graphical user interface (GUI). A GUI is not needed on this computer given that it is going to be on the robot at all times. To dispense with a GUI also allows the autonomy algorithms to use all computing resources available.

The human interface for tele-operation of the Lunabot is a PlayStation 3 Controller driven by a GUI that also shows the sensor measurements and the images from the cameras onboard. All of the software on the Lunabot computer was written in C++ and Python 2.7, and the software running on the Mission Control computer was developed on Python 2.7 using different libraries such as QT for the User Interface and Tornado for the Web Server.

On the subject of autonomy, there are two tasks to perform: Spatial awareness and Goal steering. Spatial awareness is concerned with localization of the Lunabot relative to the Lunarena, so that it can effectively know whether the robot is in the start area, obstacle area, and mining area. Goal steering is the algorithmic strategy to position the robot and to have it execute the actions required at every stage of the competition attempt. The spatial awareness computing pipeline is partitioned into the subtasks listed below – Segmentation of planes and identification of non-planar objects.

15

– Registration of the beacon located at one of the Lunarena’s walls. – Positioning with respect to this beacon

Fig. 27.

Designed Beacon

The algorithm summaries for the Registration of the Beacon is shown in Figure 30 and for planes segmentation and non-planar object identification is shown in Figure 29.

Fig. 29.

Fig. 28.

Algorithm for the identification of the beacon

The selected algorithm strategy for Goal Steering is Quadrant Navigation, which consists of dividing the bounded map of the Lunarena into squares of the same size as the robots maximum dimension, making the representation of the map as a matrix for the robot, and navigates advancing through these quadrants avoiding the obstacles, moving forward, backward, right and left. For the robot return to the starting position, the route that was taken to arrive to the mining area is saved in the robots memory so that the robot can return through that safe route.

5) Power and energy supply: For the power handling of the motors the monolithic H-bridge VNH3ASP30 it was used. This device handles a maximum of 30A of continuous current. This IC consists in a full bridge motor driver which incorporates dual monolithic High-Side drivers

Algorithm for planes and objects identification

and two Low-Side switches with their associated protection circuitry. It also implements monitoring of the load current.

As the devices silicon is packaged in a Surface Mount package, it was needed to design and fabricate PCBs to use and test it. Two PCBs were designed for the usage of this H-Bridge.

The first one was design just to test the functionality of the H-Bridge coupled to an Arduino board. With this test we noted that not all of the required digital signals from the H-Bridge were needed at all, with some of them never changing their logic state. The second PCB designed was adapted to the AMP EDGE connection, and included identified enhancements with respect to power dissipation and current steering, 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 is around 360 W, worst case scenario, and 72 W for each linear actuator, we oversized the batteries needed for the robot. We calculated the number of batteries that go on the robot so as to enable a Lunabot runtime of up to 25 minutes. That is 150% more that the actual duration of a competition attempt. The calculation yielded six 6.4 Ah @ 12 V Li-Po batteries to supply all the motors and one 5 Ah @ 22.2 V Li-Po battery to supply the linear actuators.

The electronic circuitry is supplied by the USB ports of the netbook, and a 9V battery is used as a backup for the two Arduino boards.

6) Sensing: There are 12 different sensors located on the LunaBot: Five distance sensors located at the left, right, front and back side of the lunabot to measure the distance from the lunarena walls or obstacles to the Lunabot.

The sensors are located as shown in the image below. Two sensors were placed at the back of the robot due to the high accuracy needed to park it in front of the Lunarenas regolith deposition bin.

Fig. 31.

Distance sensors location

There are 3 limit switches located at the Regolith container as shown below, to measure the amount of recollected regolith. These sensors were located according to the distribution of the regolith inside the box, so that it can be known when the excavation must be stopped and/or when 10 Kg have been excavated. These limit switches are processed using the Arduino Button library [11].

There are also 4 limit switches to monitor the actuators position. Finally, there is a Kinect sensor located at the front of the Lunabot and there is a web cam, to acquire images from the surroundings of the Lunabot.

Fig. 32.

limit switches location

7) Communications: The application of the netbook as the processing and control unit in the Lunabot implies the use of a client-server model between the Mission Control computer and the netbook. Because of this, two Python scripts were implemented: one for the server (i.e. netbook) and other for the client (Mission Control computer). Both scripts use the native Python library Socket for handling the communication between the two computers over WiFi. The router that links the two computers was configured so that the assigned IP address to the computers remains fixed, by setting up DHCP reservation for their individual MAC addresses.

At the control computer there is a script that sets up a GUI and enables a PlayStation 3 Controller to control the excavation and traction motors as well as the linear actuators.

The GUI provides a user-friendly environment that displays the data sensed at the Lunabot and the current through the motors. It also implements control of the motors and the linear actuators from the keyboard as a backup, in case the PlayStation 3 Controller fails. Since the Lunabot has the option to be autonomous, the implementation of a tele-operated mode covers us in case the autonomy fails. From the GUI the user will be able to choose among autonomous or tele-operated modes.

A communication protocol was developed between the netbook and the Arduino boards.

Since there are two of them and it is not known beforehand which port the OS assigns to them, a handshaking protocol was implemented in which the computer sends the ? symbol and the Arduino returns and M if it is the Arduino who controls the motors or and S in case it is the Arduino who controls the actuators and sensors. By this means the computer identifies

17

which Arduino is in which port and can route the correct commands to each.

Regarding the communication between the two computers in the Lunabot and Mission Control (server and client computers, respectively), the following setup is built. At the beginning the computer on the robot (server) accepts clients on the port 3000. But in case this port is blocked by another program, the server program continues to listen on the subsequent ports up to port 3100. On the other hand, the client starts by requesting a connection on the port 3000 but in case this fails, the client proceeds to request connection on the next ports up to the port 3100.

The client and server computers acknowledge each other in a similar way the Lunabot computer identifies the Arduino boards attached to it. This is accomplished by a handshaking event in which, after accepting the connection, the server sends the string Hello? and the client replies with Hi. Afterwards the server needs to authenticate the client, by parsing the user name and a password sent by the client. The result of this simple authentication procedure yields an approval or denial message. When the user is approved, the client is able to send the commands to the Lunabot.

The communication protocol was designed to consume the least amount of bandwith that was practical. Most of the commands consist of a single byte, with some exceptions. The messages that consume the most bandwidth are reply messages from the server. This messages give feedback of the status of the robot. There is a provision in the clients GUI to disable these messages.

For the image transfer a small web server was created on the netbook. The language used for this was Python 2.7 using the Tornado library.

The capture of the cameras was made with the OpenCV implementation for Python.

E. Contingency identification and risk analysis Contingencies were identified in every system and solutions were proposed to reduce the risk of each one. The results for mechanical and electronics systems are shown in tables XIII and XIV

TABLE XIII C ONTINGENCY ANALYSIS FOR MECHANICAL SYSTEMS Traction

Excavation

Chassis and elevation Discharge

All systems

Trouble Stacked/buried crawler Jamming crawler Bucker fracture Displacements of elements in shaft Structural fatigue Weld failure

Risk ++

BP1 excavated exceeds dimensions of pivoted sheet Wear due to dust interference

++

-

Solution Brooms in the side of crawlers.

Path on rollers

++

Backup buckets Seeger rings.

++

Change material.

+

Backup critical elements.

Enlarge lateral sheets.

+++

Acrylic protections for chain paths, small pores bags for motors and electronics container, plastic tubes for actuators, brushes for crawlers

F. Budget revision At this point, 55% of the budget for Phase B has been spent. Troubles caused by supplier delays generated some over costs, in specific areas, but they were covered by the expected budget. Apparently, the project will be completed without exceeding the budget. Detailed values for each area and manufacturing laboratory services are shown in Figure 33.

Fig. 33.

Budget revision phase B

G. Chronogram revision Regarding mechanical systems, the majority of the sub-systems accomplished the delivery dates, except for the container and the discharge system, due to the delay that occurred on previous phase, which had an impact of 6 weeks.

The groups associated with crawlers and structure finished their tasks in the estimated time and did not face any significant trouble. On the other hand, electronics had some complications

18

TABLE XIV C ONTINGENCY ANALYSIS FOR ELECTRONICS SYSTEMS Communication

Power

Sensing

Control

Trouble Loss of communication between Client and Server Blocked Port High current levels Current Spikes

Risk +

Induction of high currents into digital circuits

++

Failure of the relay - based control PCB for the linear actuators Limit Switch Wear

+++

Robot vibration could affect the Sharp IR sensors, causing poor performance Intense lighting affects the performance of the Kinect PC heating could cause possible shut down due to high processor usage in autonomy algorithms and signal processing.

+

Solution Handshaking between Client and Servers.

+++

Define alternative ports Widen traces on PCBs

++

Improve the Soft Start strategy.

Use of low current fuses in digital circuitry.

Insulated grounds for power and digital circuits.

Continuous replacement of the ULN2003 power driver.

++

Use high quality limit Switch and replace them continuously.

Implement a best mechanical holder for the sensors or filter data via software.

+

Kinect Calibration under different lighting condition.

–

Design a PC cooling control system using low power fans.

with autonomy system, basically caused by the delay on the rest of sub-systems.

The only sub-system that got the job done on time was sensors. At the time that all the subsystems should be presented on its 100%, the real performance was as follow: sensors 100%, communication 70%, power transmission 80% and autonomy 40%. Nevertheless, power transmission was finished two weeks later and communications system was accomplished three weeks later than expected.

V. P HASE C A. Test Design Some tests have to be designed. Test run have to ensure that system chosen accomplishes all the requirements stated. In the same way, the test will be an important tool to improve the integrated system.

1) Mechanical tests: Tests were designed for all system separately. Each one of the tests is shown as a table with parameters relevant to the feature to characterize, some of them are settled constant, others are variables. The traction test is intended to characterize its force.

The power consumption of this system can also be determined from this test.

TABLE XV T RACTION TEST DESIGN Parameter Vertical Load (Kg) Speed (m/s) Contact Area (cm2 ) Width (cm) Rotation Angle (◦ ) Linear distance (m)

Levels 10, 20, 30, 40 0,43 500 70 0,45,90,180 10

The test shown in table XV validates all traction requirements stated before.

The discharge test is intended to characterize the amount of regolith dumped out of the Lunabin.

TABLE XVI D ISCHARGE TEST DESIGN Parameter Mass (kg) Distance (cm) Discharge angle (◦ ) Pivoted sheet length (cm) Pivoted sheet deployment (◦ ) Rising velocity (cm/s)

Levels 10,15,20,25 40, 50, 60 60 20 17 3,1

Accurate values for distance parking and understand of the behavior of BP-1 during the discharge process are the intended results from this test.

The excavation test is intended to characterize the excavation rate of the system.

From this test, an optimization of the excavation rate is desired. An acknowledge of the BP1 behaviour during the excavation period is also intended.

19

TABLE XVII E XCAVATION TEST DESIGN Parameter Diameter (cm) Width (cm) Buckets (amount) Crawler’s path Motors voltage (◌ /s)

the robot was tested. The main data obtained from this test was the bandwidth consumed when receiving and sending data from and to the robot. The following data was collected from these tests using the software Wireshark for Linux.

Levels 48 10 20 Forward, backward, spinning.

8, 10, 12

TABLE XXI BANDWIDTH CONSUMPTION TEST

Structural test is intended to validate the structural integrity and to find the best performance for the chassis and the scissor lift mechanism, when the other systems are assembled to it.

TABLE XVIII S TRUCTURAL TEST DESIGN Parameter Mass in container [Kg] Voltage [V] Height [m] Actuator stroke [m] Number of continuous cycles

Levels 10, 15, 20, 25 12, 24 1,5 Stroke end 5

2) Electronics test: The H-Bridge was tested with a PWM with a frequency of 3.9K from an Arduino. At first, the correct operation of the H-Bridge was tested and the results are presented in Table XIX M AXIMUM

TABLE XIX VALUES OF I NPUT AND O UTPUT VOLTAGES IN THE H-B RIDGES

Enable A 0 5 5

Enable B 5 0 5

Output A 0 12 12

Output B 12 0 12

After verifying the correct operation of all the H-Bridges, the motors were connected under different conditions and powered using the HBridge. Each test and the result are presented in Table XX. TABLE XX H-B RIDGES TESTED USING THE MOTORS UNDER DIFFERENT CONDITIONS

Test Clockwise whirl with no load Counter- clockwise whirl with no load Clockwise whirl with 58kg load Counter-clockwise whirl with 58kg load

Result 100% 100% 100% 100%

Once it was implemented the whole designed mentioned before, the teleoperated control of

Test Robot movement commands BW Webcam images BW Kinect images BW Total BW

Level (Mb/s) 0,15 1,56 Mb/s 2,2 Mb/s 3,91 Mb/s

In order to test the IR sensors that were going to be located in the Lunabot (front, back, left, right), a small prototype of the robot was designed and all the 5 sensors were placed on it. The Sharp IR sensors were connected to an Arduino MEGA and then the following data was recovered from several analysis regarding some key features needed for the final implementation. The calibration curve was then inverted and linearized so it could be used a proportional relation between sensed distance and output.

TABLE XXII IR SENSORS TEST Parameter Minimum sensing distance (cm) Maximum sensing distance (cm) Dissipation current (mA) Ambient light tolerance Output voltage with a 5V power supply (V)

Levels 23 110 27 Yes 0,5 - 4,8

Its not worth mentioning the results obtained when the tests with the limit switches were done. This is because these switches doesnt present an appreciable power dissipation nor any other key feature for its implementation.

3) General test: Finally, a test for the integrated system was designed. Conditions of Lunabotics Mining Competition were simulated for the global test, the robot was intended to make the same process as in competition attempt, and requirements tested are shown in Table XXIV. None of the tests explained before have been run rigorously, dates for each one are estimated and stated on table XXV.

20

TABLE XXIII G ENERAL TEST Trouble Roller stocked because of regolith.

Wasted regolith through the wheel.

Bearing damage due to regolith.

Discharge out of lunabot.

WebCam distortion due to regolith Kinect Distortion due to regolith Over Heating in electronics

Mechanical

Electronical

this phase Correction Screw path on the roller.

Canal enlarged Bearing support reoriented Parking improvement Improve the digital filter Add a new Digital filter Include a fan

TABLE XXIV R EQUIREMENTS CHECKED IN GENERAL TEST Parameter Autonomy Loaded straight movement (>10 kg) Structural failure Lost communication Loaded maneuverability (>10 kg) Minimum Excavation (>10kg) Travel time (min) Excavation time (min) Discharge time (min) Power supply time (min)

Requirement Yes/Not Yes/Not Yes/Not Yes/Not Yes/Not Yes/Not <3 <5 <1 >15

TABLE XXV E STIMATED DATES FOR TESTS .

Mechanical

Electrical

Test Traction Discharge Excavation Chassis Scissors H-BRIDGES Bandwidth consumption IR Sensors Autonomy General

Date 23-Apr 24-Apr 24-Apr 25-Apr 25-Apr 26 - Apr 30 - Apr 27 - Apr 2 - May 04-may

Fig. 34.

Budget expenses for phase c

D. Chronogram Revision Even though the group had some delays in phases A and B, the project is actually on a 80% of its development. According to schedule, the only job that has not started yet is the test of the integrated systems (mechanical and electronic). Some tasks exceeded its planned time but others were before planned, at this point, few tasks remain undone.

VI. C ONCLUSIONS A. Budget conclusions At this point, 80% of the project is completed and around 55% of the budget has been spent.

Nevertheless, expensive purchases and services will be needed in the remaining tests and corrections.

A projection of the future expenses predicts that the project will spend around 94% of the target budget, as shows Figure 35. To conclude, the budget stated was enough to cover all phases expected during the project.

Fig. 35.

Budget expenses

B. Corrections Even if the rigorous test have not been run yet, 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 preliminary tests have been run and some corrections were needed. The purchase of material used for corrections has spent 35.62% of the budget for Phase C. Figure 34 shows budget expenses for

B. General conclusions System engineering guidelines were followed to accomplish a Lunabotâ&#x20AC;&#x2122;s design process, according to requirements stated by NASA. Thanks to their experience, last year participants involved in the team enriched the entire process, their problems and success from last year were the starting point for many of the systems tested and selected this year.

The structured process over the last 9 months involved not only team members but also a

21

lot of people through academic courses in the Universidad de los Andes. This cooperation allowed them to participate in Phase A, by proposing their own ideas, producing prototypes and learning from robotics principles and helped Robocol to decide its final design.

At this point, Robocols Lunabot is almost finished, some corrections need to be done to start final tests and finish validation process.

Since the entire process was done rigorously, good results are expected in LMC 2012, in which excavating and depositing at least 10 kg of regolith during official attempt sessions is expected.

R EFERENCES [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-forming giant 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 Third Annual Lunabotics Mining Competition Rules and Rubrics and Rubrics,” January 2012.

[5] H. Omori, T. Nakamura, T. Yada, T. Murakami, H. Nagai, and T. Kubota, “Excavation mechanism for a planetary underground explorer robot.” in ISR/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: Development, Design, Application, ser. Series on Bulk Materials Handling. Trans Tech Publications, 1975.

[Online]. Available: http://books.google.com.co/books? id=IkJkQgAACAAJ [7] R. Norton, Design of Machinery: An Introduction to the Synthesis and Analysis of Mechanisms and Machines, ser. Engineering Series. McGraw-Hill Higher Education, 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 of planetary exploration rovers on loose soil: Research articles,” 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 sensor igp2y0a02yk datasheet.”

[Online].

Available: 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