Acquisition of 3D Ground-Penetrating Radar Data by an ... · This dissertation details the design and development of a mobile autonomous platform from which to conduct a 3D ground-penetrating

Acquisition of 3D Ground-Penetrating Radar Data by anAutonomous Multiagent Team to Support In-Situ Resource

Utilization

by

Francis Frenzel

A thesis submitted in conformity with the requirementsfor the degree of Masters of Science

Graduate Department of Aerospace EngineeringUniversity of Toronto

Copyright c© 2010 by Francis Frenzel

Abstract

Acquisition of 3D Ground-Penetrating Radar Data by an Autonomous Multiagent

Team to Support In-Situ Resource Utilization

Francis Frenzel

Masters of Science

Graduate Department of Aerospace Engineering

University of Toronto

2010

This dissertation details the design and development of a mobile autonomous platform

from which to conduct a 3D ground-penetrating radar survey. The system uses a three-

rover multiagent team to perform a site-selection activity during a lunar analog mission.

The work took place beginning in 2008 and culminated in a final field test on Mauna

Kea in Hawaii. This demonstration of autonomous acquisition of 3D ground-penetrating

radar in a space robtic application is promising not only for in-situ resource utilization,

but also for the concept of multiagent teaming.

ii

Contents

1 Introduction 1

1.1 In-Situ Resource Utilization . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Lunar Analog Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Autonomous Ground-Penetrating Radar Acquisition . . . . . . . . . . . . 11

1.4 MultiAgent Teaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 System Design 17

2.1 Basic Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Electronics and Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Electronic Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.2 Environmental Enclosures . . . . . . . . . . . . . . . . . . . . . . 36

2.2.3 Remote Operations Systems . . . . . . . . . . . . . . . . . . . . . 38

2.3 Ground-Penetrating Radar Acquisition . . . . . . . . . . . . . . . . . . . 39

3 Control 46

3.1 Survey Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2 Line Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3 Trace Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4 Other Software Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5 Hardware Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

iii

4 Integration 58

4.1 Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2 Transmission Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4 TriDAR Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5 Testing 64

5.1 In-House Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2 Sudbury Integration Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3 Hawaii Field Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6 Results and Conclusions 82

7 Closing Thoughts and Future Work 93

8 References 96

iv

Chapter 1

Introduction

1.1 In-Situ Resource Utilization

In-Situ Resource Utilization (ISRU) is the basic notion of making use of the native

materials of asteroids, moons or even planets to sustain human activities. With the sole

exception of solar energy, all materials and energy needed to complete any previous space

exploration mission have been gathered, assembled and launched from Earth. It is for

this very reason that all missions in space have been limited to exploration. A permanent

or even a sustained presence on the Moon, Mars or any other planetary body necessitates

the use of locally available substances due to both economic and logistic reasons. In past

manned missions, all rocket propellants, air, food, water, oxygen and human habitats

have been brought aboard the launch vehicle in their entirety. ISRU technologies are

being investigated to enable a portion of these consumables to be harvested while de-

ployed. Sanders & Duke [2005] identify potential space resources as “water, solar wind

implanted volatiles (hydrogen, helium, carbon, nitrogen, etc.), vast quantities of metals

and minerals, atmospheric constituents, unlimited solar energy, regions of permanent

light and darkness, and the vacuum and zero-gravity of space itself. Suitable processing

can transform these raw resources into useful materials and products.” The same report

1

Chapter 1. Introduction 2

goes on to highlight four major areas where ISRU will positively impact future missions:

• Mission consumable production (propellants, fuel cell reagents, life support con-

sumables, and feedstock for manufacturing and construction),

• Surface construction (radiation shields, landing pads, walls, habitats, etc.),

• Manufacturing and repair with in-situ resources (spare parts, wires, trusses, inte-

grated systems etc.),

• Space utilities and power from space resources.

Applied to actual scenarios these benefits translate to mass, cost and risk reduction as

well as increased mission flexibility and capability. With such a promising revolution in

space travel and exploration, it is no surprise that ISRU has generated a great deal of

interest from parties such as NASA, ESA, JAXA and of course, the source of our funding,

the CSA.

Apart from the near-term benefits such as mass and cost reduction which simply make

space travel increasingly feasible, the era of ISRU missions is undeniably the techno-

logical realm which will take our civilization to new and distant locales. To transport

all necessary consumables for the entire mission duration is already severely taxing on

operational capability and science capacity for manned missions to nearby bodies such

as the Moon and Mars. The trip duration required to move beyond, to the extremities of

the Solar System or even further, to the nearest stars, necessitates ISRU. To endure the

long voyage there, and likely back1, these future missions must incorporate the native

resources of distant locations.

In the long-term, ISRU will become our primary method of space exploration through

sheer necessity. However, Sanders & Duke [2005] investigate a host of motivations

1Not to imply a failed mission, but rather a expeditionary enclave, setting out to found a permanenthuman colony.


to start pursuing ISRU sooner rather than later. The most obvious and immediately

impactful benefit from ISRU is the decreased launch mass required through mid-mission

refuelling using locally harvested and processed propellants. “For example, a lander that

is designed to carry a fully fuelled ascent vehicle for initial human missions, can later

carry an increased payload mass to the surface equal to the ascent propellant load if

in-situ propellant production is incorporated”[Sanders & Duke 2005]. The notion of

mid-mission refuelling is extended beyond acquiring propellants through a processing

plant payload, to the concept of space depots as refuelling stations. By establishing a

propellant depot in Earth Orbit or Earth-Moon libration points, the cost of Lunar and

Martian exploration missions could be significantly reduced. Transporting fuel from the

Moon to either Earth orbit or a libration point is more efficient than transporting from

Earth due to the significantly reduced gravitational pull from the Moon. The benefit

from space depots increases with the distance travelled since the transportation vehicles

avoid carrying both the return propellant, and the propellant required to transport the

return propellant. Sanders & Duke [2005] highlight a study by Rapp [2005], showing

that using hydrogen and oxygen fuel, harvested from lunar polar water and delivered to

low-Earth orbit reduces the mass launched from Earth by 40%.

Mass reduction can also directly influence the living conditions of the astronauts in-

volved. For example, the mass of radiation shielding included in a mission is balanced

with the acceptable risk for crew exposure during missions beyond Earth’s magneto-

sphere. As mission durations increase, this risk accumulates and so the need for shield-

ing becomes greater. The use of local materials for radiation shielding greatly lowers the

implicit cost of carrying these materials and thus the balancing between acceptable risk

and shielding cost is swayed in the astronaut’s favour.

ISRU is also likely to have significant benefits for mission energy budgets. In fact

it is suggested that this may be the first way ISRU is included in future deployments:


“Until ISRU is adequately demonstrated, mission planners will be hesitant to incorporate

ISRU into mission critical roles in future human missions. To provide this confidence,

while providing immediate payback to the mission, ISRU can be incorporated into early

robotic and human missions to produce mission consumables that can then be used to

extend the original mission duration”[Sanders & Duke 2005]. Applied to Lunar power

generation Duke et al . [2002] found that ISRU reduces launch weights for one-megawatt-

class generation systems by a factor of ten when compared to Earth delivered equipment2.

This implies that ISRU can provide ten times the power output per delivered kilogram

of power system, drastically increasing infrastructure capacity. In the long-term, ISRU

could even allow energy to be returned to Earth through harvesting of Helium-3. With

further progress in fusion technology the Moon may prove to be a reliable source of fuel

for the reactors. Along with bringing consumables back from space for energy, near-Earth

and main belt asteroids could provide a host of valuable commodities. These bodies are

rich in minerals including cobalt, nickel, and platinum which, based on estimates may be

worth billions of dollars[Sanders & Duke [2005]].

The Moon is undoubtedly the first destination for a major ISRU implementation.

This is outlined in Sanders et al . [2007], where three primary objectives are detailed

for Lunar ISRU:

1. Identify and characterize resources on the Moon, especially the polar region,

2. Perform early demonstrations of ISRU on the Moon in preparation for human

exploration of Mars,

3. Develop and evolve Lunar ISRU capabilities to support sustained, economical hu-

man space transportation and presence on the Moon.

2For comparison, the World’s largest photovoltaic facility, generates 80 megawatts and sits on over900 acres of land outside Sarnia, Ontario.


With a fully developed outpost on the Moon, the eventual goal is to expand the eco-

nomic sphere of the Earth to include the Moon. A permanent human presence on the

moon requires the ability to generate basic commodities such as oxygen, hydrogen and

nitrogen needed to sustain human life, and provide propellant. Without the necessary

infrastructure to produce or extract these elements, a long-term human habitation is

impossible. Thankfully, many potential sources of these elements have been identified.

In fact, Taylor & Carrier [1993] detail 20 methods of obtaining oxygen on the Moon.

Cutler & Krag [1985] present compelling evidence that the reduction of ilmenite is

the prime candidate for in-situ lunar oxygen acquisition. Similarly, the lunar highland

material anorthite has been identified as source of oxygen when smelted. Oxygen can

also be found as iron oxide on the Moon in which case oxygen can be obtained by heating

the material above 900◦C in the presence of hydrogen gas. This process is made more

practical by the discovery of hydrogen-containing regolith at the lunar poles[Nozette

emphet al. 1996]. This is inline with NASA’s plan to establish a lunar outpost at

Shackleton Crater, near the Moon’s south pole. Since the interior of this crater is in per-

petual shadow, it is hypothesized that it acts as a cold trap which preserves harvestable

volatiles implanted from comet impacts. Combined with results from, the Lunar Prospec-

tor3 mission’s Electron Reflectometer and Magnetometer showing an increased presence

of solar-wind implanted hydrogen due to magnetic field anomalies, the Shackleton Crater

rim is an obvious choice for the harvest of lunar regolith. Apart from element extraction,

lunar regolith can also be used as a basic building material. In a form similar to con-

crete, ‘mooncrete’[Beyer 1985] could be used to construct habitats and various other

infrastructure elements. Regolith can also be used in its raw form for radiation shielding

or surface elements such as berms, landing pads and roads. As such, there is a great deal

3Lunar Prospector was also equipped with a gamma-ray spectrometer which identified aluminum,calcium, iron, magnesium, oxygen, potassium, silicon, thorium, titanium, and uranium. Many, if notall of these materials could certainly be used to support human activities in-situ, or as commoditiesreturned to Earth.


of interest in the handling, transport and excavation of lunar regolith. This is evidenced

by the development of several commercially available simulants such as MLS-1, MLS-2,

JSC-1a and CHENOBI.

Owing to the harsh environment and the cost of man-hours of vs robot-hours, the ma-

jority of the work done at the site is expected to be completed autonomously by robots.

In particular, before the site is established, site-preparation work will be completed en-

tirely by autonomous robotic agents. As these robotic precursor missions are essential to

creating a foothold on the Moon and for ISRU in general, many studies have investigated

the optimum design for such rovers. The manipulation of regolith is the prime capability

necessary in early site-preparation and as such robotic regolith harvesting has been the

focus of design studies investigating optimum rover configurations [Maniscalco et al .

[2007], Whittaker et al . [2009]]. Preliminary estimates presented by Whittaker et

al. [2009] suggest that preparation of a berm and a landing pad should take approxi-

mately six months given the proposed mission scale.

Besides excavation capability, robotic precursor missions may also incorporate the

ability to sinter the leveled landing pad, further mitigating ejected debris and surface

collapse due to thrusters of potential landers. A recent study [Gamsky & Metzger

2010] has suggested sintering may be necessary on Mars if landers are of the weight class

necessary to transport humans. While it may be absolutely necessary for Mars, it is

likely that sintering a landing pad would improve its performance and longevity in the

face of multiple landings. As such, this technology was included in the 2010 joint field

test described in the next section. Metzger et al . [2010] conducted an investigation

into the effects of thrusters on native soil to assess the similarity between local tephra

and lunar regolith.


While site-preparation is a critical first step towards a lunar outpost, it is only one of

a plethora of technologies and capabilities necessary to establish a human presence on

the Moon. The working relationship between various ISRU operations is delineated in

NASA’s ISRU vision and can be seen in Figure 1.1. This is a final vision of the full scope

of a preliminary permanent human outpost which would surely develop over the course

of many years and several cooperating missions. A significant portion of the necessary

components are currently in development with various prototypes vying for inclusion in

deployment, which is expected to commence within the decade.

Figure 1.1: This illustration shows a web of technologies necessary to establish a manned

ISRU presence on the Moon and is taken from Sanders et al . [2007]. The central focus of

the entire development is the processing of native materials. This is in support of all other

activities in the base, demonstrating ISRU’s potential to allow permanent settlements on

foreign planetary bodies. In many of the capabilities in the figure a mobility platform

is needed, particularly in regolith harvesting and site construction. Development of a

multipurpose modular chassis could fulfill several roles if designed correctly.


1.2 Lunar Analog Mission

To highlight the newest developments in technologies for the establishment of a lunar

outpost, the Northern Centre for Advanced Technologies(NORCAT) organized a joint

ISRU field test which brought together “over 100 personnel from six NASA centres,

CSA, Natural Resources Canada, DLR, Universities from the US, Canada and Germany,

and at least eleven private companies from the US, Canada and Germany”[Schmidt,

Boucher & McTaggart 2010]. The site for the field-test was the Pacific International

Space Center for Exploration Systems (PISCES), primarily because the site is comprised

of “soil and terrain widely acknowledged as being among the closest analogs to lunar

regolith”[Fox et al . 2008]. The volcanic tephra located over 2700m up Mauna Kea is

a good representation of lunar soil and landscape, and thus this site was chosen as the

destination for the joint ISRU field test. The UTIAS contribution to the event was

a demonstration of site-selection and preparation; however, the same chassis was also

used as a platform for the RESOLVE drill for resource and site characterization, and

the ‘load-haul-dump’ for regolith excavation and transport. Other groups demonstrated

carbothermal smelting for oxygen production as well as sintering and various other ISRU

related experiments.

While robotic teams are expected to play a role in many ISRU activities, this research

focuses on the first mission to establish the most basic of infrastructure: a landing pad

for the vehicles necessary to transport humans and supplies to the lunar base. The

construction of the landing pad entails four separate components: first, and the focus

of this dissertation, acquisition of a 3D subsurface map of the area to determine the

suitability of the site, excavation of a 25m diameter-landing pad, building a berm around

the landing pad and lastly, creating an access road to transit to and from the landing

pad. The experimental setup is as shown below in Figure 1.2 where the GPR survey area,

landing pad, access road and berm are all within the field-of-view of a Neptec-designed


imaging device called a TriDAR. This vision system implements Triangulation Distance

And Ranging using a laser and is capable of producing a mesh of points which represent

a 3D surface map. Demonstration of the landing construction task is critical as the

development of a reliable landing site on the Moon is intended to open up the door to

future missions to prepare the site further for human habitation.

Figure 1.2: This is a depiction of the experimental setup for the UTIAS component of the

lunar analog mission. The TriDAR is used to generate a 3D terrain map of the surface.

This is particularly useful during site selection and the excavation tasks such as landing

pad clearing, berm forming and road clearing. The GPR survey area is intended to cover

the entire area of operation for all excavation tasks.

The autonomous construction of a lunar landing pad is a complex task which must

be completed with minimal resources. Therefore it is necessary to ensure the excavation

activity is only attempted in a location where the task is within the operational capability


of the rovers. To avoid multiple excavation attempts a thorough site-selection procedure

is used. First the potential site is surveyed using Neptec’s TriDAR which produces a

3D surface. The data from this scan is then transmitted back to to CSA headquarters

in St-Hubert where a decision is made to situate the landing pad and the access road

in a particular location. This decision is preformed using ExDOC, a command and

control centre based out of the CSA in Quebec. Once the operator has established that

there are no insurmountable obstacles, the site-selection activity proceeds with the GPR

component.

The goal is to acquire a GPR-generated subsurface map to complement the TriDAR-

generated 3D surface. In this way mission control is given a full view of any impediments

which may lay above or below the surface, and can thus direct the mission accordingly.

The GPR survey will be conducted autonomously by a team of three rovers. Human

operators control the mission from the ground control station (GCS) using a monitoring

and control graphical user interface (GUI). The data gathered during the survey is used by

a participating company, Xiphos Technologies Inc. to do analysis and eventually produce

a graphical 3D subsurface map. Once the go-ahead has been given based on the GPR

survey, one final hurdle must be cleared. That is, the ground will be sampled to render

a precise composition of the soil. This task will be performed robotically as well. The

entire decision process is outlined in Figure 1.3 detailing all steps as well as the parties

responsible.

Objectives Our specific objective for the GPR portion of the site selection task is to,

given a set of bounding coordinates, provide data to Xiphos with which to construct a

subsurface map. In compliance with Xiphos’ Interface Control Document [Caillibot &

Sado 2009a] we seek to provide a compressed file which contains a .top survey overview

file, as well as .hd and .dt1 files for each line. The actual contents of each file are explored

in further detail in Section 4.1. The specifications we hope to achieve are three-fold:


1. Acquire a full 25m× 25m survey

2. Line spacing of 0.5m or lower

3. With each line being comprised of traces no more than 0.05m apart.

By completing a survey with the above parameters it is hoped that a subsurface map may

be constructed with sufficient resolution to identify any rocks or other obstacles which

may be too large for our rovers to move. By doing so we hope to contribute to a growing

confidence in ISRU capabilities for future deployments as well as to demonstrate the

merits of multiAgent teaming (MAT). In Chapter 6 we discuss why the first specification

had to be relaxed in order to complete the task in the given timeframe for the Hawaii

field test, although three complete surveys were sent to Xiphos during in-house testing

before the final deployment.

1.3 Autonomous Ground-Penetrating Radar Acqui-

sition

GPR is a multidisciplinary, noninvasive imaging technique which is able to map un-

derground features by means of radio waves. Recently, autonomous GPR acquisition has

been a major research pursuit as a method for detecting landmines while minimizing

human risk [Motoyuki et al . 2006, Najjarin & Goldenberg 2005, Navish & May

2006]. Being a powerful surveying tool, there is significant interest in operating GPR on

a mobile autonomous platform, as evidenced by ESA’s inclusion of GPR on its ExoMars

rover[Vago et al . 2006]. GPR will be used as a tool to identify subsurface water on Mars

and this process has been modelled using a human operated cart[Furgale, Barfoot

& Ghafoor 2009]. GPR has also been proposed as a critical instrument in the explo-

ration of the lunar surface by Kohout et al . [2009], and Barfoot D’Eleuterio &

Annan et al . [2003] put this notion to work by developing a mobile platform capable of


autonomous acquisition. However, this work only attempted to acquire 2D scans, stating

that 3D model acquisition was the final goal. This is the general trend in that mobile

autonomous GPR acquisition has been limited to ‘line-scanning’ where a GPR unit is

towed over an arbitrary trajectory profiling a cross section of the subsurface. Some 3D

GPR scans have been conducted autonomously [Slob Groenenboom & Fokkema

2003, Groenenboom van der Kruk & Zeeman 2001] however this was not done on

a mobile platform, but was conducted by actuating a GPR around a defined area using

an apparatus with servomotors. A similar testbed was used during experiments which

not only articulated an arm for 3D mapping, but also had autonomous object detection

software in use[Herman 1997]. The final conclusion of this research was that the system

should be mobilized and that “in order to do this, we need to automate an excavator to

be used both for scanning and excavation.”A recent experiment by [Fong et al . 2008]

used a mobile robotic platform to acquire an extended 2D scan with many passes through

an area, but didn’t orchestrate the movement in such a way that the data could feasibly

be used to construct a 3D subsurface model. While there has been work done towards

modeling the sensor data needed to construct a 3D subsurface map by [Beck & Osborn

1991], the autonomous collection of 3D subsurface data in space robotic applications is

yet to be demonstrated. It is thus the goal of this thesis to demonstrate the first com-

pletely autonomous collection of GPR data used to construct a 3D model by a mobile

platform. Specifically we hope to demonstrate that this capability can be implemented

in a robotic-led mission to the Moon.

1.4 MultiAgent Teaming

MultiAgent Teaming(MAT - also MulitAgent Team) has been identified as key strategy

in autonomous robotics and is applicable to various tasks across the field. The goal

of MAT is to distribute a task amongst a team of cooperative agents to increase the


robustness of the system and avoid the single-point failure potential of an individual

agent. This is in contrast with traditional systems such as [Stentz et al . 1998], which

focus entirely on a single agent. In addition to eliminating single-point failures, MAT

allows teams to be easily expandable or reducible and also enables the workforce to

concurrently complete tasks at various sites. While MAT provides many benefits it also

requires a great deal of communication infrastructure between the rovers as well as an

innovative control scheme which ensures that the rovers cooperate and work together to

achieve the task. The current work builds upon much work done by the UTIAS Space

Robotics Group to demonstrate the capability of MAT.

Prior to the current rover system, the Argo rovers (which themselves are derived from

work on smaller LEGO robots) were the principle platform used for MAT research at

UTIAS. One of the Argo rovers can be seen in Figure 1.4. These rovers enabled the

Space Robotics Group to investigate several problems in multiagent control such as rover

following, resource gathering and landing pad excavation. The purpose of these rovers was

to provide a proof of concept for MAT behaviours and develop the technical expertise to

operate a team. Figures 1.4 and 1.6 showcase these rovers completing resource gathering

and excavating tasks, respectively.

While the Argo rovers were equipped with a blade for excavation, more work needed

to be done on real-time closed-loop blade control before it was possible to move forward

with the Musketeer concept. To demonstrate this a next generation, larger rover was

created to begin experimenting with blade control. The UTIAS NORCAT EVC Mobility

Enabled Excavation Platform (UNEMEEP) was showcased at the 2008 Planetary and

Terrestrial Mining Sciences Symposium, highlighting the autonomous blade control based

on force feedback. This permitted moving forward with the development of our current

MAT, the Musketeers. Moving along towards a space deployment, the Musketeers will

likely be a motivation for a next level prototype after successfully demonstrating the


intended tasks.


Figure 1.3: The potential procedure used to control an autonomous site construction

project involves several parties. The focus of this thesis is the MAT GPR survey. The

team of robots are equipped with a GPR unit for this component and are later used with

a blade for the excavation tasks.


Figure 1.4: A predecessor to the current platform, one of ten Argo rovers is shown in the

UTIAS experimental dome.

Figure 1.5: This series of photos showcase the Argo rovers completing a resource gathering

task using an evolved neural controller, demonstrated by Thangavelautham, Smith,

Boucher, Richard & D’Eleuterio[2007]

.

Figure 1.6: Using another evolved controller, Thangavelautham, Smith, Abu El

Samid, Ho, Boucher, Richard & D’Eleuterio, [2008] orchestrate the Argo rovers

into an excavation task.

Chapter 2

System Design

Owing to the varied operating conditions of the Musketeers (the summer and winter at

UTIAS, the Ethier Sand and Gravel Pit outside Sudbury during the winter and 2700m up

Mauna Kea in Hawaii) and the intense workload of excavation, a key design requirement

in every aspect of the system was always robustness. There are several environmental

stresses that must be considered in the rover design such as dust, wind, rain, snow,

extreme high and low temperatures and high humidity. Wherever possible outdoor-rated

ruggedized options were chosen, and provisions were made to enclose sensitive equipment.

This section discusses the basic system components comprising the rover and not actually

how to use them. The appendix details, practical operation as well as software interfaces.

Although our current platform is only focused on site preparation, design consider-

ations for mobility and modulariy were made to extend the abilities of the rovers to

complete many of the tasks outlined in Figure 1.1 such as resource and site characteriza-

tion, polar volatile extraction, regolith excavation, regolith transport, surface construc-

tion, mobile transport of oxygen, surface mobility asset in future prototypes. This is in

line with the final vision of one of the design concepts identified in 1.1: “The long-term

concept is for a fleet of robotic vehicles to work together on the Moon. They would be

supervised by one or two operators on Earth or in a regolith-covered lunar control station,

17

Chapter 2. System Design 18

and return to a base station for cleaning, battery exchange, module reassignment and

routine maintenance”[Maniscalco et al ]̇. As the current set of rovers is designed to

work as a team, while all wielding blades, they have been dubbed the Musketeers. The

individual rovers took on the names of the characters from the literary work The Three

Musketeers, donning the titles, Aramis, Athos and Porthos.

2.1 Basic Platform

To enable the demonstration of MAT, a team of three, independent and identical rovers

are used. Each chassis is designed around the concepts of mobility and modularity. By

using a ‘U’-shaped frame, large payloads can be exchanged through the opening at the

front of the rover. The chassis itself then provides some protection for any potentially

sensitive payload. Furthermore, the ‘U’ shape allows the payload to be mounted at

the centre of gravity of the rover providing additional stability on uneven terrain. The

suspension and drive-train are both also designed to maximize mobility. All four wheels

are driven by two 24V DC motors; one mounted on each side, driving two wheels. In this

way the left and right sides of the rover are driven independently and the rover utilizes

‘skid-steer’ or ‘tank-drive’ locomotion. The torque is transmitted to the wheels using a

chain-driven walking beam transmission which pivots at a central point just below the

motor. The walking beam allows the wheels to articulate more than using independent

mounting points and thus was chosen for increased performance on uneven surfaces.

To further improve the tractive effort of the platform, a coupled pivot suspension links

the port and starboard walking beams. This system redistributes a port walking beam

articulation evenly into the starboard side, and vice versa. The coupled pivot ensures that

all four wheels are in constant contact with the ground by keeping the deflection in each

suspension equal in magnitude and opposite in direction. The power for rover is provided

by two 12V rails of six parallel lead-acid cells located in each arm of the chassis’s ‘U’.


Connected in series the two rails provide 24V for three systems: the RoboteQ AX2850

motor controller, the electronic control and sensor system and lastly for the payload.

With a long battery life and a rugged, off-road chassis, the rover is well-suited to the task

of site-preparation in a raw lunar landscape.

The rover chassis were manufactured by Ontario Drive and Gear Limited in New Ham-

burg, Ontario and shipped to Sudbury, Ontario. Ontario Drive and Gear designed the

rovers based on a study investigating mobility platforms conducted by Neptec. Electronic

Vehicle Controllers Limited then outfitted the rovers with the power supply system and

the motor controller. The two payloads, GPR and blade, were also manufactured in

Sudbury by NORCAT. The chassis and payloads were then shipped to UTIAS to begin

installing the chosen suite of sensors and electronics. We were charged with developing

a small control payload to sit at the base of the ’U’, consuming the first 35cm of the

payload slot. This location houses the MCB and MIB and contains all of the electronics

necessary to monitor the rover while also acting as the seat of control, commanding the

Musketeer through any of its tasks.

2.2 Electronics and Sensors

Operation of any remote or autonomous system requires a suite of sensors capable of

providing sufficient information about the local environment to allow intelligent control.

This applies both when the Musketeers are operated in the typical autonomous fashion

as well as during any remote, human controlled procedure. Sensors were chosen so as

to satisfy a broad set of necessary sensor capabilities as follows: obstacle avoidance,

navigation and positioning, blade control for excavation/GPR arm articulation, mobility

and system status, and subsurface scanning. Figure 2.1 outlines the electronic control

suite for an individual Musketeer. What follows are the specific sensors and devices

chosen, their basic characteristics and the rationale for selected them.


Figure 2.1: The electronic architecture used to automate the rovers for GPR acquisition.

All the components are detailed in this section.

2.2.1 Electronic Suite

Musketeer Control Computer

• Device Part ID: S101,

• Manufacturer: ASUS,

• Main Data Interface: Ethernet, USB,

• Nominal Power Draw: 36W ,

• Weight: 1kg,

The keystone of the entire electronic system, the main processing unit, handles all

control and sensor feedback required for processing. All data generated by every system


Figure 2.2: Musketeer Control Computer

on the rover is received, handled and processed on board the vehicle by this computer.

Three options were explored to act as the MCC: Gumstix Verdex, XTI’s Q5A, and

intel-based laptops. The Verdex and Q5A are much smaller, consume much less power,

and as miniature processing boards, are the type of solution which would eventually be

used in space-qualified versions of this project. Despite this, a conventional laptop-style

computer was chosen based on four main advantages: reduced software development to

control rover systems, greater processing power necessary for evolved neural controllers

and GPR data processing, a laptop can act as a link between the onboard LAN and the

entire Musketeer WLAN, and it was also felt that it would be much easier to troubleshoot,

test and develop during experiments. The selected computer, both from a size and

processing power perspective is the ASUS EeePC.

The EeePC is a small form factor laptop based on the Intel Atom Processor. The Atom

is a low power, hyperthreading microprocessor running at 1600MHz with a 512KB L2

cache. The S101 has 1GB of DDR2 memory and a 16GB solid-state drive as well as

an integrated SD slot that is high-capacity compatible and equipped with a 16GB card.

Microsoft Windows XP was chosen as the operating system since many of the sensors


had existing software packages for windows which sped up the development process.

Upon receiving them, one EeePC was put through a series of tests to benchmark its

performance and robustness under environmental stresses similar to what may occur

during the operation of the Musketeers. The tests found the cpu performance, drive

throughput, memory performance, network connectivity and network throughput all to

be satisfactory while running in low temperatures (−10C), high temperatures (30C),

high humidity (100%RH), as well as constricted ventilation and vibration scenarios.

Figure 2.3: Electronic Speed Controller

Electronic Speed Controller

• Device Part ID: AX2850,

• Manufacturer: RoboteQ,

• Main Data Interface: RS232-DB15,

• Nominal Power Draw: 2.4W ,

• Weight: 1.5kg,


• Environmental Limits: −40◦C to + 85◦C,

This device was selected by Electronic Vehicles Limited to provide power to the rovers’

motors during both autonomous control and human teleoperation. The RoboteQ con-

troller converts RC PWM, wireless modem, or microcomputer commands into high volt-

age and high current output for driving the two NPC motors on the Musketeers. The

motor controller is rated for a maximum of 240A peak draw at 12V to 40V DC. The con-

troller’s two channels can be operated independently or mixed to achieve skid steering.

The speed controller is equipped with quadrature optical encoder inputs for closed loop

speed and position control. Numerous safety features are also incorporated into the con-

troller in its various modes of operations to ensure reliable and safe usage. To properly

size the quadrature encoder for odometry measurements, calculations with respect to the

motor shaft speed and the gear reduction rates were conducted. Using these calculations

and measurements of the wheel sizes, the controller was calibrated so that commands

could be given to the RoboteQ in terms of ground speed in metres per second.

Figure 2.4: Ground Penetrating Radar

Ground Penetrating Radar

• Device Part ID: Noggin 1000,

• Manufacturer: Sensors & Software Inc.,


• Main Data Interface: Ethernet (serial to NIC and Ethernet from NIC to MCC),

• Nominal Power Draw: 8W (not including associated NIC),

• Weight: 1.5kg,


The Noggin, manufactured by Sensors & Software Incis the basic scientific instrument

contained in the Musketeer’s GPR payload. Internally, the unit consists of a transmitter

and two antennas. Radio waves emitted from the transmitter are reflected at interfaces in

the subsurface, and these reflected waves are received at the antennas. The time between

emission and reception gives an indicator as to the depth of the interface while the

intensity of the reflected wave denotes the attenuation at that depth. During operations,

the Noggin acquires this data which is stored onto the MCC in real-time. The Noggin

unit is highly ruggedized and has been used previously with the UTIAS Space Robotics

group’s ARGO rovers[Barfoot, D’Eleuterio & Annan 2003]. Sensors & Software

Inc. Manufactures three variants of the Noggin with varying transmitting frequencies. A

higher frequency permits higher-resolution scanning; however the signal attenuates much

more rapidly and thus the scanning depth is limited. Conversely, a lower-frequency

Noggin gathers data over a much deeper field of view, albeit at a low resolution. As the

excavation site chosen will be the optimal location found using the TriDAR-generated

surface map, the construction of the landing pad should not require digging more than a

metre of soil. The highest frequency unit available is the Noggin 1000 which transmits at

1000MHz. This is capable of imaging the first metre of subsurface and thus is the sensor

able to give us the best subsurface map over our area of interest. For this mission the OEM

version of the Noggin 1000 is used to allow direct communication and control without

needing Sensors & Software’s proprietary control hardware. This version includes a

Network Interface Card (NIC) allowing an operator to control the Noggin using Ethernet.


Figure 2.5: OMEGA SCADA

Supervised Control and Data Acquisition

• Device Part ID: OMB-DAQ-3001,

• Manufacturer: Omega,

• Main Data Interface: USB,


• Weight: 0.4kg,


For real-time, closed loop control of the actuators for the blade and GPR payloads, a

SCADA unit is needed with several input and output channels operating at high frequen-

cies. The OMEGA OMB-DAQ-3001 data acquisition unit handles feedback regarding the

stroke of all actuators (measured by reading a screw-driven potentiometer) and for the

blade payload load cells relay horizontal and vertical force readings. This information

is processed on the MCC which then issues commands to the SCADA which in turn,is

also used to drive the actuators. The data acquisition unit features 16-bit/1-MHz A/D

converter, 16 analog input channels, four 16-bit/1-MHz analog outputs, 24 high-speed


digital I/O, 2 timer outputs and four 32-bit counters. This particular model was chosen

for reliability and expandability as well as its fully developed GUI based development

software.

Figure 2.6: Inertial Measurement Unit

Inertial Measurement Unit

• Device Part ID: 3DM-GX2,

• Manufacturer: MicroStrain,

• Main Data Interface: RS232-microDB9,


• Weight: 0.04kg,



An inertial measurement unit is needed for two primary purposes: Firstly, it is needed

during blade control to keep the cut level and, second it is needed to estimate the orien-

tation of the rover. The 3DM-GX2 manufactured by MicroStrain is an attitude heading

reference system AHRS used for vehicle pose estimation and localisation. The vehicle

body tilt data is particularly critical for real-time blade adjustment. The rate sensors,

along with the magnetometer readings give rough estimates of odometry and heading in

order to localize the Musketeer. This device also has a very high update rate, customiz-

able from 1-250Hz to provide AHRS information for localisation and blade controller

use. This 3DM-GX2 is low cost, low power, and has small form factor, rendering it an

attractive sensor to enhance the capabilities of the Musketeers.

Figure 2.7: Trimble GPS

Primary Localisation

• Device Part ID: Pathfinder PRO XRT,

• Manufacturer: Trimble,


• Main Data Interface: Bluetooth,

• Nominal Power Draw: Internal rechargeable Li-Ion battery, 13 hour life,

• Weight: 1.5kg (not including 0.6kg antenna),


Although not a feasible option for a lunar ISRU mission, GPS was chosen as the

primary means of localisation since it is an established and trusted technology, and it

was felt that there would be less development time needed for integration. The Trimble

unit chosen is essentially a stand-alone device with an internal battery, communicating

wirelessly with the MCC through Bluetooth. The PRO XRT is GLONASS enabled, and

through a subscription to OMNISTAR HP, it provides position data with accuracy as

high at 10cm.

Figure 2.8: UBlox GPS

Secondary Localisation

• Device Part ID: Ublox-EVK-5H,

• Manufacturer: Ublox,



• Nominal Power Draw: < 2.5W ,

• Weight: 0.02kg,


The Ublox-5H GPS receiver was essential in the development, testing, and calibration

of the Musketeer behaviours and onboard sensors. The GPS receiver is low cost, low

power, and has small form factor allowing for easy integration into the sensor suite. This

GPS unit was only intended for use during the developmental and testing phase of the

project while a final decision for localization was made. The Evaluation Kit (EVK)

consists of the Ublox-5H in a protected casing as well as a software kit to allow for a very

short software development time. The Ublox-5H features 4 Hz update rate and -160dBm

tracking sensitivity for indoor or difficult or poor reception applications.

Figure 2.9: LIDAR

LIDAR

• Device Part ID: LMS111,

• Manufacturer: SICK,

• Main Data Interface: RS232,



• Weight: 1.1kg,


A LIght Distance And Ranging (LIDAR) system is a crucial element in any robotic

activities requiring terrain mapping, navigation, obstacle avoidance, and visual odometry.

Although not needed during the deterministic GPR control, the SICK Laser is necessary

for obstacle avoidance during excavation tasks. The LMS111 features 20m range, 270◦

horizontal field of view, 0.5◦ angular resolution, and is rated for outdoor applications.

Capable of scanning at either 25Hz or 50Hz the LMS111 is ample for our purposes. The

primary use for this device is obstacle avoidance, however further development could

enable terrain mapping, localisation between vehicles, and navigation.

Figure 2.10: Pan-Tilt Unit

Pan-Tilt Unit

• Device Part ID: PTU-D46,

• Manufacturer: Directed Perception,




• Weight: 1.3kg,


To make full use of the SICK Laser the unit’s field of view must be independent of the

orientation of the rover. This is particularly important when turning, when the SICK

Laser must rotate in anticipation of the turn to ensure the path is clear of obstacles.

To satisfy this need the SICK Laser is mounted on Directed Perceptions PTU-D46.

This pan-tilt unit (PTU) has two axis of rotation allowing the SICK Laser to view any

particular point on interest. The motors in the PTU are very sensitive allowing angular

specification at resolutions up to 0.003◦.

Figure 2.11: Thermal Sensors

Thermal Sensors

• Device Part ID: VK011,

• Manufacturer: QualityKits,



• Nominal Power Draw: < 1W ,

• Weight: < 0.1kg,


The thermal sensors were not originally anticipated, but as the rovers began undergoing

large-scale tests it was discovered that the motors were overheating. The VK011 was

chosen primarily because it was very easy to interface with, integration was simple, and

the data output was easy to process. All of these were crucial considering this sensor was

not purchased until six weeks before deployment. The VK011 supports up to four single

wire thermometers, and so temperature feedback is made available for each of the two

motors, as well as for the MIB and the ambient temperature.

Interfacing Devices Because the EeePC has only two USB ports and one Ethernet

jack, connecting the various sensors requires a set of interfacing and communication

devices. To facilitate communication between the MCC and the sensor suite data signals

were converted to Ethernet wherever possible and connected via a switch to form a LAN.

Figure 2.12: Perle Convertor


Serial to Ethernet Conversion

• Device Part ID: SDS4-T,

• Manufacturer: Perle Systems,

• Main Data Interface: RS232, Ethernet,


• Weight: 0.3kg,


The Perle system serial to Ethernet converter provides a means to convert all RS232

signals into Ethernet protocols. The SDS-4-T features 4 RJ45-10pin port for RS232

signal input and can operate at extreme temperature ranges. The serial to Ethernet

converter is essential to standardize the signals coming from the various sensors on the

Musketeers.

Figure 2.13: Lantronix Convertor

USB to Ethernet Conversion


• Device Part ID: UBox2100,

• Manufacturer: Lantronix,

• Main Data Interface: USB, Ethernet,


• Weight: 0.3kg,

• Environmental Limits: 0◦C to + 40◦C,

The Lantronix converter accepts two USB inputs and converts them into Ethernet

protocol. This enables standardized coding architecture between the various devices

communicating through the network. The device supports USB 2.0 with full duplex,

achieving maximum data transfer speed between devices on the network.

Figure 2.14: Switch

Ethernet Switching Capability

• Device Part ID: SD208,

• Manufacturer: Cisco,

• Main Data Interface: Ethernet,



• Weight: 0.4kg,


The Cisco SD208 is a 8 port 10/100 switch providing the capabilities necessary to setup

an internal network. The internal network will facilitate communications between the

sensors and the MCC. This allows the MCC to connect to all sensors through a single

Ethernet connection to the on-board LAN, greatly reducing the number of cables and

connections to the MCC.

Figure 2.15: Long-Range Wireless Adapter

Long-Range Wireless Networking

• Device Part ID: HWUG1,

• Manufacturer: Hawking Technology,


• Nominal Power Draw: Powered through MCC via USB,


• Weight: 0.4kg,


The Hawking HWUG1 is a 2.4Ghz Wireless-G, USB network adapter which is used to

facilitate wireless communication between the Musketeers and ground control. Although

the MCCs have an integrated wireless card the HWUG1 was needed to provide adequate

signal strength for field operations. The Hawking device not only has a larger effective

range, but the removable antenna allows the signal to be transmitted from outside the

MCB as opposed to the MCC’s internal wireless adapter. For this reason the HWUG1

was a critical component of the Musketeer communication infrastructure.

2.2.2 Environmental Enclosures

While some sensors like the PRO XRT and Noggin are ruggedized and durable through

severe weather, dust and shock scenarios, the majority of the electronic systems are

extremely sensitive to extreme conditions. As a result it was necessary to fashion an

enclosure for the various devices to shield them from environmental stresses. A water-

tight and air-tight case manufactured by Pelican was chosen as it is the standard in

protective enclosures. The decision was made to enclose the MCC in its own case, the

‘Musketeer Control Box’ (MCB), and the other, non-ruggedized devices in the ’Musketeer

Interface Box’ (MIB). In this way the MCB is rapidly interchangeable in the event of a

computer failure, and needs only one Ethernet cable and one power cable to fully link it

to the rover’s electronic system. Figure 2.16 shows an initial 3D mock-up of the MCB,

as well as the final case, including the MCC, secondary localisation, Hawking wireless

adapter and circuitry necessary to externalize the MCB power button and indicator

lights.


Figure 2.16: A photo of the Musketeer Control Box. The MCC is visible and operates

while shut in the case during experiments.

To ensure that the MCC is isolated from contaminates the MCB cannot be opened in

the field. For this reason it was necessary to create a small circuit (viewable just behind

the monitor of the MCC in the actual picture) which allows the MCC to be turned on

by a switch on the outside of the case. The circuit also allows the MCC power and hard

disk activity LEDs to be relayed outside the case. The Hawking wireless adapter has

an antenna which allows the signal to be transmitted from outside the case, and this

antenna is visible sticking out of the top of the MCB. The computer sits on a large metal

heat sink with fins extending out of the bottom of the case. All connections are located

at the side of the case and cables with weather-proof connectors are used in conjunction

with dust and water resistant connectors on the case which are sealed with epoxy.

The MIB uses the same case as the MCB and contains the IMU, switch, Ethernet-

USB convertor, Ethernet-serial convertor, and 3 Vicor DC-DC convertors. The Vicor

convertors are used to take the 24V power supplied by the batteries and step it down

to 12V , 8V and 5V to accommodate the power requirements of the various electronics.


These are mounted on the circuit visible in Figure 2.17. The circuit also serves to

relay information outside the case in a similar fashion to the circuit in the MCB. Power

indicators, internal temperature and rover voltage are displayed on the case using LEDs.

The details of the MCB and MIB electronics are detailed in Gammell [2010].

Figure 2.17: The Musketeer interface box houses the equipment necessary to integrate

the entirety of the Musketeer’s electronic suite.

2.2.3 Remote Operations Systems

The remote operation of the Musketeer team requires a control station with an es-

tablished wireless connection to the rovers from which commands can be issued, system

diagnostics can be monitored and issues with any device can be resolved. To this end two

computers form a WLAN with the Musketeers through which they have access to the

entirety of the onboard electronic suite. The Ground Control Station (GCS) is the main

control computer for the Musketeer team and it is from this terminal that the operators

issue all high-level mission commands. The GCS runs a Graphical User Interface (GUI)

which enables the operators to easily monitor critical system status indicators such as

motor temperatures, battery levels, estimated GPS accuracy along with additional rele-


vant feedback from other sensors. The GCS is also where the GPR data from each rover

is compiled into a single package at which point the GCS acts as a server allowing XTI to

access the data through HTTP. The network architecture permitting this communication

is highlighted in Figure 2.18. The Ground Support Station (GSS) is a second terminal

used alongside the GCS to permit greater flexibility in the operation of the rovers. In

case a device on a rover experiences technical difficulties the operators can diagnose and

resolve the problem on the GSS, leaving the GCS available to maintain normal moni-

toring and control activities with the other rovers. The GCS and GSS can be seen in

Figure 2.19 during the field test at Mauna Kea.

Figure 2.18: Illustrated in the Musketeer communication architecture, through which

GPR data is transmitted from the Noggin unit, to the MCC and finally through the

GCS to Xiphos Technologies

2.3 Ground-Penetrating Radar Acquisition

GPR is an effective subsurface mapping instrument which can be used to generate

a 3D model of the underground topography using the data acquired from a completed

survey. Conventionally, a survey is acquired manually by an operator using a tow-behind


Figure 2.19: A photo of the ground control station and ground support station during

operations at the final field test. The GUI is visible on the monitors to the left.

combined transmitter/receiver unit. To facilitate the autonomous acquisition of such a

survey, a great deal of modifications must be made to the standard, human-operated

unit. First, the concept of GPR and the acquisition process is discussed, followed by a

description of the GPR payload used by the Musketeers.

GPR data is used to generate 2D or 3D models by compiling a series of 1D ‘traces’

which are individual data points detailing the composition of the ground at a point. Each

trace is acquired by the GPR’s transmitter emitting a radio wave into the ground and

then having the receiver record the timing and intensity of the waves which are reflected

back to the surface. The interface between various components of the subsurface such

as soil, rock, clay, sand or water causes part of the radio wave to be reflected back, and

the magnitude of this reflected wave is proportional to difference of the two mediums’

index of refraction. For example the interface between a layer of sand and a layer of soil

would reflect back a much weaker wave than that of a soil/rock interface. After the wave


is emitted from the transmitter, the receiver ‘listens’ and records the magnitude of all

the reflected waves in a timing histogram. Once the speed of light in the native soil is

determined, the amount of time between emission and reception is used to determine the

depth that the interface occurs at. In this way each trace is somewhat akin to a core

sample taken at a particular point.

By acquiring a series of traces in row, GPR can be used to see a cross-sectional slice

of the ground. This collection of traces is called a line and generally is formed using

traces spaced at most a few centimetres apart. These lines are the final product for

GPR applications such as determining ice-thickness and locating underground cables

and piping. For more intensive subsurface mapping requirements such as archaeology,

forensics and of course the lunar site-selection task, a set of lines can be combined to

form a full 3D survey. The hierarchy between traces, lines and surveys is illustrated in

Figure 2.20. Such as the structure of a GPR survey is, the autonomous system must

be capable of deploying a GPR unit on the ground, traversing slowly while traces are

acquired and repeating this process several times until a full survey is gathered.

While the Musketeers still make use of a conventional GPR unit, several adaptations

must be made to allow for autonomous acquisition. In general, the apparatus which

the GPR unit is mounted on is made almost entirely out of plastics as any metallic

object distorts the radio signal used by the GPR. Since the aluminum and stainless

steel rover chassis itself would render GPR acquisition impossible were the unit directly

in the payload slot, the GPR payload consists of a long fibreglass arm which allows

the Noggin to be mounted approximately a metre from the main rover body, as shown

in Figure 2.21. Giving interference further consideration, Teflon hardware was used to

assemble the payload wherever possible. To allow the rover to drive normally with the

GPR payload installed, it is necessary to have the arm capable of actuating to keep

the GPR off the ground and avoid damage during transit. The mounting point for the


Figure 2.20: This drawing highlights the hierarchy of the various GPR components. The

trace is a histogram of timining intensities, and when combined in series, several traces

provide a line of data. Several of these in turn can be used to construct a 3D model.

actuator is a slotted connection allowing the GPR unit 34cm of passive vertical travel so

that it may always maintain contact with the ground while avoiding damage. Keeping the

Noggin in constant contact with the ground is absolutely critical as an air gap between

the unit and the surface completely distorts the data. The magnitude of the reflected

wave is proportional to the difference in the index of refraction between the two surfaces

comprising the interface, and between air and a solid this difference is much larger than

would be encountered within the subsurface. For this reason, the vast majority of the

signal is immediately reflected upon contacting the ground, and minimal information can

be retrieved about what lies below. Any air gap then creates significant artefacts in the


data set and can compromise the operator’s ability to assess the subsurface topology.

Ensuring this was not an issue required a mid-testing modification to the GPR sleigh

discussed below.

Figure 2.21: A rover outfitted with a GPR payload during early testing at UTIAS.

The Noggin is sold with a durable plastic shell, resistant to dust and shock, however

the unit was further ruggedized by encasing it in a Teflon sleigh for three reasons: firstly

the custom sleigh permits the GPR mounting points to be optimized for the fibreglass

arm (as opposed to the Noggin’s mounting points), using Teflon as opposed to plastic

further reduces the coefficient of friction allowing for easier traversing, and lastly the

sleigh further protects the Noggin for autonomous acquisition. A human operator is

capable of making slight adjustments to the speed or angle of the GPR cart as they

push it so as to reduce abrasion or shock from contact with rocks or other obstacles. As

the autonomous control is limited in this capability it is necessary to further protect the

unit. In addition to this a human operator can easily detect when the unit is no longer

in flush contact with the surface and adjust accordingly. To address this capability the


sleigh was outfitted with a small cable to limit the maximum deflection of the GPR about

the horizontal plane as shown in Figure 2.22. However during preliminary testing it was

found that the sleigh would often get dragged at its maximum deflection, rendering the

gathered data useless. To solve this issue the cable was replaced with a spring so that a

restoring force returns the sleigh to the flush position after any intermittent deflection.

This modification is highlighted in Figure 2.23.

Figure 2.22: This pair of photos shows the sleigh and the original deflection prevention

device. The sleigh is propped up in the image on the right.


Figure 2.23: Similarly, this figure shows the sleigh and the modified deflection prevention

device. The image on the right shows the sleigh propped up with tension on the spring.

Chapter 3

Control

There are two major aspects to the control of the Musketeer team. The various elec-

tronic systems used require software to monitor their statuses, request data and send

commands. In addition to the low-level hardware control, software is also needed to

execute the tasks needed for site-selection and preparation. This high-level, behavioural

control dictates the various actions the rovers make, and makes use of the low-level code

to interact with the various devices needed. The two control types can be delineated

as the technical component which directly interacts with the hardware and the theoret-

ical counterpart which orchestrates the various devices to acquire a survey. The fully

autonomous collection of a GPR data set involves several independent controllers to ex-

ecute the entire behaviour. Just as there is a hierarchy in that several traces form a line,

many of which comprise a survey, there is a need for a survey controller, which makes

use of a line controller that runs a trace controller. We begin by discussing the overall

survey controller.

3.1 Survey Controller

The survey control is the master controller which dictates which rovers are to complete

which lines within the survey. Once given coordinates defining the survey’s boundaries,

46

Chapter 3. Control 47

the controller divides the region into three equal components so that each rover has its

own area to operate in. There are four possible modes that the rovers can be instructed

to complete the survey in. These are outlined in Figure 3.1. Depending on the speed of

rover transit, the reversing modes can slightly decrease the total survey time. Although

it does not perform as well as the other three modes, mode one was chosen for the final

field test in Hawaii to conform to the requirements of the company doing analysis on the

data.

Figure 3.1: This figure highlights the trajectories of the four modes under which the

Musketeers are capable of acquiring GPR data.

In every mode the rovers are given a set of way points that they must first navigate

to. This is completed using a closed-loop way-point tracking software (Section 3.4).

Upon reaching the way-point defining the start of a scan line the rovers rotate such that

they are directed towards the terminal point of the line. This is completed using second

closed-loop software which orients the rover with respect to the Earth’s magnetic field

using input from the IMU (Section 3.4). Depending on the operator’s desired mode of


survey acquisition, the rovers either wait at this stage, ready to acquire a line, until all

rovers are in place, or each rover can continue independent of the status of the other

rovers. To begin scanning, the survey control then calls the line-acquiring controller

(Section 3.2) which begins by lowering the GPR and activating the transmitter. After

traversing the line, the controller finishes with the GPR raised and ready for transit before

turning control flow back over to the survey controller. With the scan line completed,

the GPR data is transmitted to the GCS through the WLAN. At this point the survey

controller checks the motor temperatures to make sure the motors are not over-heating.

The threshold used within the survey controller is set to 70◦C, and is intended to activate

an early response which will delay scanning the next line until the motor has cooled down.

During the entire duration of any rover activities, the GUI itself is monitoring the motor

temperature and will force a hard-stop on any controller running once the threshold

temperature (85◦C) is reached. If the temperature is acceptable the rovers will wait for

other rovers to finish their lines if the operator has elected to run with this option. If not,

each rover will continue independently of the other rovers and navigate to the origin of

the second scan line. This process continues until all lines have been completed, at which

point a survey overview file is generated. This file (discussed in Chapter 4) is intended

to hold the overall survey characteristics such as line-spacing as well as the total number

of both lines and traces and is packaged with the data files of the individual lines. The

entire process is shown in Figure 3.2.

There are several parameters which must be specified by the GCS when issuing the

command to begin the survey. These parameters pertain to both the actual GPR ac-

quisition as well as the closed-loop controls. The large number of parameters allow the

scans to be fully customizable and able accommodate any mission requirements at run-

time. The procedure is then flexible, particularly with respect to desired GPR survey

resolution. The attempt is to have as little as possible hard-coded into the software so


Table 3.1: Parameters used in GPR surveys, * only needed for first version of driving

software (Section 3.4).

Parameter Description

Survey Site Corners GPS coordinates defining the survey region, given in local Cartesian (m)

Rover Speed - Transit Speed at which the rovers transit to the next way-point (m/s)

Rover Speed - GPR Speed at which the rovers drive while acquiring traces (m/s)

Line Spacing Distance between successive scan lines (m)

Trace Spacing Distance between traces in a scan line (m)

Orientation Threshold How accurately the rover orients itself (rad)

Position Threshold How accurately the rover attempts to reach a way-point (m)

Maximum Drive Time * Maximum amount of time the rover will attempt to transit (s)

Maximum Rotate Time * Maximum amount of time the rover will attempt to rotate (s)

Trace Stacking Number of traces to collect and average at each point

Points Per Trace Number of data points in a trace

Trace Acquisition Rate How often the GPR gathers traces (Hz)

that code does not have to be edited and recompiled during any testing procedures. The

only values which are hard-coded are the gains for the way-point following and rotation

closed-loop controls. Table 3.1 provides a list of all the necessary parameters and briefly

describes each.

3.2 Line Controller

The controller which acquires lines is at the next level of hierarchy in the control

structure and is called by the survey control. Once this control is initiated, it begins by

lowering the GPR arm and commanding the Noggin GPR to turn on its transmitter and

begin reading the trace values received at its antennas. The function of the line con-

troller is then to drive along the desired path, all the while running the trace acquisition

controller. Once the line is begun a .dt1 data file (Section 4.1) is created, and as traces

are gathered the new data is appended to the existing .dt1 file. The rover then acquires

a line using either V0, V1 or V2 (discussed below).

Three different versions of the line controller were brought to Hawaii. Beginning with

the simplest, V0 is the version which was tested in Sudbury. This version is very sen-


sitive to errors in initial alignment of the rover before it begins each line, as the rover

will simply drive in a straight line once commanded to start. The rover monitors the

encoder feedback and continues driving with symmetric speed commands to both port

and starboard channels until the desired distance has been reached. This version can

easily be perturbed as it is an open-loop control which will not respond to terrain slope

or obstacles which prevent the rover from traversing in a straight line.

The next iteration of line controller, V1, is based on V0 and has the addition of an

extra closed-loop controller. Whereas in V0 both port and starboard are driven with the

same velocity, V1 drives the sides independently so that the rover can be turned if it is

perturbed and moves off-course. One difficulty in implementing this controller is that

any sharp turns can damage the GPR arm if it is deployed on the ground. Therefore,

although the wheels are driven independently, a hard clamp is enforced on the rover’s rate

of angular rotation to prevent any damage to the GPR unit and sleigh. The closed-loop

control added in V1 is a proportional controller which operates based on the difference

in the current heading and the desired heading using IMU feedback. This will ensure

that rover lines are always parallel, however it is possible for the rover to correct itself,

and end up acquiring a line which is translated slightly from the initial line position.

To correct for this error an additional closed-loop controller has been added into V2.

In this line controller, based on V1, the proper line length is ensured (as per V0), the

direction and straightness is maintained (as per V1), and lastly, V2 keeps the rover

navigating along the intended trajectory, not allowing the rover to accidentally acquire

a parallel, but translated line as could occur in V1. To do this it is necessary to have a

high GPS accuracy as the controller operates on the distance between the rover’s current

location and the intended scan-line. A second proportional controller is added which first

calculates the distance from the line using the rover’s current position and the terminal

points of the line. Using this data it is straightforward to obtain the current translation


away from the desired position using the formula for distance from a point to a line.

Since this controller works against the controller in V1 (V1’s controller opposes turning

away from parallel to the scan line) harmonizing the proportional constants of the two

controllers is particularly critical to ensure that V2 is able to bring the rover back to the

line and have it continue driving with the proper heading.

Once any of the three line controllers have terminated, the Noggin GPR is commanded

to stop acquiring traces, and the actuator lifts the GPR arm back into the raised position.

The line controller then generates an .hd line-overview file described in Section 4. At

this point the control flow returns to the survey controller.

3.3 Trace Controller

The trace controller is used to gather traces from the GPR unit at the appropriate

locations. While the GPR is operating, it constantly acquires traces at a constant rate

and stores them in a buffer located in the NIC. The trace control accesses this buffer

and writes individual traces to the current .dt1 file. Once the line controller initiates

it, the trace controller constantly monitors the distance driven. Based on the specified

trace spacing it periodically gathers traces from the GPR NIC. The trace controller

is responsible for getting the trace data on the MCC, parsing out the required data,

stripping off the standard header, appending a custom header, and then writing the data

in binary form as specified in Section 4.1. The trace controller continues gathering traces

at the specified interval until the line controller terminates it at the end of the run when

the line has been completed.

To ensure the success of the activity, a fine balance must be achieved between the

rover speed and trace acquisition rate. In our experiments the trace acquisition speed

was determined empirically. The GPR collects traces at a constant time interval (specified


by the trace acquisition speed as per Table 3.1) and stores them in a buffer. If, for a

given trace spacing and rover speed the acquisition rate is too slow, when the rover gets

to the next trace location, a trace will not yet have been acquired and thus the buffer

will be empty. Using a higher trace acquisition speed guarantees a greater likelihood

that when the MCC requests the buffer, the most recent trace will be of the ground

directly underneath the current position. However a greater acquisition rate corresponds

to a larger buffer size which requires more bandwidth and can create latencies in data

transmission. In addition, this generates a significant computational load for the MCC

in that it has to handle a larger buffer and also has more data to parse when isolating

the most recent trace. In fact, often it is the case that when the acquisition rate is too

great, the CPU usage is so high that by the time the MCC has queried the encoders to

read how far it has traveled, the rover has already passed the next location and missed

the trace.

A balance between these two factors must be found in accordance with the Rover Speed-

GPR parameter and the Trace Spacing parameter (Table 1). The trace acquisition speed

used in testing (Section 5) was determined experimentally given the desired rover speed

and trace spacing. This was done using a module which allows the operator the ability

to closely monitor the trace controller as it monitors distance, acquires buffer contents,

and writes individual traces to the .dt1 file.

3.4 Other Software Controllers

In addition to the above, GPR-specific controllers, there are two additional con-

trollers used in the survey acquisition process. Firstly, the SCADA is operated using

a proportional-integral-derivative (PID) controller which is also used in the excavation

activity. Each actuator (one for the GPR payload, three for the excavation payload)

takes an input voltage to drive the actuator and has a potentiometer which can be used


to infer actuator position from the voltage returned. After corroborating the potentiome-

ter voltage with position for each actuator, it is possible to drive the actuator using a

PID loop in the SCADA server. In this way the line controller only has to specify the

position to set the actuator to when raising and lowering the GPR arm.

Furthermore, a controller is used for basic locomotion. This controller is also used

in excavation and drives the rover to a specified location and orientation given in local

Cartesian coordinates and an angle with respect to north. The final version of the code

used the driveByTraverse way point tracking software[11] which was written midway

through GPR development. Prior to this a temporary locomotion controller was used

which operated by attempting to maintain the proper heading at all times. The rover was

guided by a proportional controller which would turn the rover based on the difference

between the current bearing and heading. The heading is provided by the IMU while the

bearing is calculated as the angle of the line connecting the rover’s current position with

the final destination. Once the rover is in position a rotational controller pivots the rover

on the spot to obtain the desired orientation. The final version of this controller used a

proportional controller acting on the difference between desired and current heading as

given by the IMU.

3.5 Hardware Control

The survey, line and trace controllers are all wrapped into an application entitled

GPRSurvey.exe. This allows the operator to make use of any of the GPR capabilities

of the Musketeers from the GCS. The program is a single-point of communication for

the user since it interfaces with all the necessary servers for all sensors and actuators.

The software structure used to coordinate the rovers during GPR operations is shown

in Figure 3.3. The ground control operators have access to two computers, the GCS

and the GSS. The GSS is used as a link into the MCC’s for direct system diagnostics


and maintenance in case any of the device servers crash. On the GCS two programs

are being displayed, the GUI is for monitoring system status, emergency stopping and

thermal monitoring. The program GPRSurvey.exe is where the operator specifies the

survey parameters, commences GPR surveys, and tests the various aspects of the survey

software during boot up procedures (see Appendix). In addition to being monitored by

the GCS and GSS, each device is monitored by a logger client which runs on each MCC.

This is used to record all data so that rover failures can be analyzed after they occur.

To use GPRSurvey.exe, all the required servers must be started locally on each MCC.

This is done during boot up by remotely connecting to the MCC’s as described in the ap-

pendix. The necessary servers are detailed in Figure 3.3 in the row of sensors/actuators.

Each sensor uses the same client/server interface as shown to speed up software develop-

ment. Just as the hardware architecture was designed to streamline as many sensors as

possible through Ethernet, the software to control the various elements of the rover was

designed to unify all devices under a common communication structure. Inheriting from

Space Robotics Group’s previous generation of Argo rovers, the Musketeers run on the

same software suite entitled ArgoSoft, albeit at the updated version 5.1.

The basis of ArgoSoft is a robust, cross-platform compatible communication architec-

ture which uses an ArgoServer to interface with a piece of hardware, and an ArgoMod-

uleInterface client to speak to the device through the server. The advantage of such a

relationship is that each sensor can be used by multiple applications without any inter-

ference. This is established by using a protocol involving a proprietary communication

structure where all servers communicate using a data packet called an XportMSG. In

this way all clients communicate with servers in the same ‘language’ regardless of what

sort of interface actually exists between the server and the sensor. To make use of this

functionality, any program which connects to a server must implement the client side

based on ArgoModuleInterfaces. In Figure 3.4 this relationship is illustrated showing the


communication to the GPR using Argosoft with GPRSurvey.exe as the client program.

A particular device class is added to ArgoServer for each piece of hardware that needs

to be incorporated into the system. To access this device, the appropriate server must

already be running on the MCC, so that basic communication with the device is estab-

lished. To interact with the server an instance of ArgoModuleInterfaces is written to

pair up with the ArgoServer counterpart. Client programs from any computer connected

to the MCC through Ethernet, can then implement ArgoModuleInterfaces to establish

direct communication to the device through which commands can be issued and data

retrieved.


Figure 3.2: The survey acquisition process with three rovers.


Figure 3.3: This diagram shows which software applications communicate with the indi-

vidual devices on the rovers.

Figure 3.4: The ArgoSoft framework.

Chapter 4

Integration

The full site-selection activity has multiple components which all need to work in

unison to achieve success. As such it was essential to have a integration test where the

efforts of the various members (CSA, Neptec, UTIAS) were successfully combined. The

goal of this test was to work out any kinks in the communication infrastructure so as

to ensure a smooth final field test. Development of the GPR system for the Musketeers

was always geared towards the final deployment at the full ISRU site-selection and site-

preparation activity at a lunar analog site in Hawaii. This chapter discusses the efforts

made to integrate the various systems for a smooth final operation. In this chapter the

efforts to integrate the GPR acquisition activity with other components of the mission

are discussed.

4.1 Data Format

The format of the GPR data has been outlined in Xiphos’ “ISRU GPR Server ICD,”[Caillibot

& Sado 2009a] and has been chosen to conform to the data types used by Sensors &

Software. The trace data consists of a series of paired integers. The data points express

the time delay between emission and reception of a radar pulse as well as the signal atten-

uation during that time window. The number of pairs of data is configurable by changing

58

Chapter 4. Integration 59

the number of points per trace. This data, combined with a 128-byte header recording

position, time and basic GPR information, comprises the binary .dt1 files. Each .dt1 file

includes the data for an entire scan line by simply appending traces at the end of the file

as the line is acquired.

In addition to the basic trace data, two overview file types are also provided. An ASCII-

formatted .hd file accompanies every .dt1 file and contains the fields in Table 4.1. The

entire survey’s metadata is collected in a XML-formatted .top file. The fields included

in each .top overview file are detailed in Table 4.2. Some of the metadata in the .dt1

and .hd files are not used in the analysis but they are included nonetheless so as to

comply with Sensors & Software’s existing file types. The survey data is then compatible

with Sensors & Software’s analysis suite and can presumably be used to compare and

benchmark Xiphos Technologies’ analysis efforts.

4.2 Transmission Architecture

This subsection details the transmission of data between the Musketeers and the GCS

as shown in Figure 4.1. The next subsection however, is concerned with the entire

transmission architecture including Xiphos Technologies’s data-analysis cpu, the Hybrid

Processing Card (HPC) and CSA command through ExDOC. All commands to the

Musketeers are issued directly through the GCS using the adhoc WLAN network. The

GPR survey begins by the potential site coordinates being transmitted to the GCS. At

this point GPRSurvey.exe appropriately divides the survey area into subareas for each

rover to scan. The rovers then begin scanning their areas independently. The original

configuration had the rovers storing all .dt1 and .hd files locally until the survey was

complete, at which point the entire sub-area survey is dumped onto the GCS. To ensure

robustness and the ability to resume a survey in case of failure the final version of code

transmits the data at the end of each scan line. Once the all the .dt1 and .hd files are


Table 4.1: The data fields in a .dt1 file.

Field Description

Number of traces Number of traces in the associated .dt1 file

Number of points per trace Number of data points/pairs of integers per trace

Timezero at point Time offset from delay between transmission and reception

Total time window Amount of time required to acquire the line

Starting position Distance from the Y-axis to the start of the line

Final position Distance from the Y-axis to the end of the line

Step size used Distance between traces

Position units Units of measurement for the all distance readings

Nominal frequency Frequency of Noggin GPR unit in MHz

Antenna separation Distance between transmitter and receiver antennas

Pulser voltage Voltage applied to transmitter antenna

Number of stacks Number of traces averaged for a single collected trace

Survey mode GPR setting pertaining to how the antenna collects signals

Table 4.2: The data files in a .top file

Field Description

Number of traces Sum of the traces from each line

Number of lines Number of lines in the survey

Line spacing Spacing between each line in metres


received the GCS creates a .top file and compresses all files associated with the current

survey into a .tgz file.

Figure 4.1: The transmission architecture for the Musketeer team.

4.3 Analysis

The .tgz file representing the entire survey is hosted in a directory on the GCS which is

accessible to XTI as a server through conventional TCP/IP. After unpacking the contents

of the survey on the HPC the trace data is converted into a 3D subsurface map outlining

what is contained in the first metre of ground. The procedure and software used to

construct the map are outlined in a document published by Caillibot & Sado [2009b].


Lastly, the 3D map is hosted on a server accessible by the ExDOC PC, from which the

decision of whether or not to proceed with the potential site is made. If approved for

site-preparation this is the final step in the GPR survey activity. If the subsurface is

deemed to be unsuitable for excavation the site-selection activity begins anew searching

for a candidate site. The flow of information from the Noggin all the way to ExDOC is

shown in Figure 4.2.

Figure 4.2: The flow of data from the Noggin itself through the File Systems (FS) of

each of the MCC, GCS, HPC and ExDoc PC are shown. The entire path of the trace

data from acquisition to model construction and finally analysis with the visualization

application at ExDoc is shown.


4.4 TriDAR Interface

Other than providing GPR data to XTI, the other major data interface necessary for

the Musketeers is between the GCS and the TriDAR. While markedly more important

to the excavation component of the ISRU activity, communicating with the TriDAR

was still an important milestone during the Sudbury integration testing. TriDAR scans

are triggered automatically by the ground control GUI at a user-specified interval during

excavation and can also be triggered manually at any time. The TriDAR has a NIC and so

is accessible through the Musketeer WLAN. In this way the GCS can access the TriDAR

using an IP just as if it was another rover. During testing both in Sudbury and Hawaii

Neptec was responsible for setting up the TriDAR and connecting it to the network.

Neptec provided UTIAS with a set of executable files which can be used to communicate

with the TriDAR. The first executable initializes the device with parameters for that

day such as the TriDAR’s exact location as well as coordinates for reference points and

various other scanning parameters. By calling the second executable the TriDAR writes

a .org file to a specified location. This file is then parsed by the GUI to extract a 3D

array defining the surface topology in the TriDAR’s field of view. This can then be used

for calculating the next areas to be excavated or can be used to visualize the progress

made.

Chapter 5

Testing

This Chapter discusses the various stages of testing up to and including the final field

test in Hawaii. Included are test plans, preliminary results, and details of issues that

arose during testing and how they were solved. Figure 5.1 is a timeline showing the basic

periods of development and testing in the Musketeers life cycle. The results of the final

test in Hawaii are left to the proceeding chapter as the final product of this research.

Unfortunately, for many of the tests the final 3D models were never shared with UTIAS.

In addition to this, UTIAS was not included in the analysis of the maps and thus can

only evaluate our success based on the ability to provide data sets and not on the actual

data generated. Testing and development of the system can be roughly divided into three

categories: in-house testing done at UTIAS, the Subury integration test, and the final

Hawaii field-test.

5.1 In-House Testing

The vast majority of development and testing took place at UTIAS. While much of the

electronic integration and development was done inside the lab, the basic testing ground

for site-selection activities was outside in the UTIAS back field. Figure 5.2 is a satellite

photo of the area showing some basic landmarks in the area as well as the proposed

64

Chapter 5. Testing 65

Figure 5.1: Timeline of Musketeer development

location for a landing pad. Figure 5.3 was taken shortly after an excavator tilled the

area so that the Musketeers could work in pure soil as opposed to having to dig through

grasses and weeds. In this location the rovers were subject to various environmental

conditions from high heat and humidity during the summer, to blizzard-like conditions

during the winter and every version of wind, rain or other adverse weather in the interim.

Being that one of the primary design considerations was the ruggedness and durability of

the entire rover system this mix of conditions proved to be a much needed confirmation

of the Musketeers hardiness.

The first stage of development for the Musketeers was ensuring the full functionality of

the electronics necessary to perform the first driving tasks. This included writing drivers

for the IMU, secondary GPS and RoboteQ. Once these systems were operational the

first control algorithm was developed and tested. The early way-point tracking software

discussed in Section 3.4 used a bearing-aligned driving technique and was the first demon-

stration of autonomous behaviour by the rover team. Figure 5.4 shows some preliminary


Figure 5.2: A satellite image of the UTIAS grounds.

trajectories of the rover navigating towards a point from various surrounding locations

during the tuning stage of the algorithm’s development.

Upon completion of the locomotion control, the rotational control mentioned in Section

3.4 which permitted the rover to rotate on the spot using IMU feedback was developed and

tested. At this stage the rotation occurred at a constant angular velocity and had to be

kept very slow to avoid overshooting. After the Sudbury deployment this was changed to

a proportional control to achieve better performance. With the basic locomotion software

intact, the next set of testing incorporated these behaviours into the genesis of the overall

survey controller discussed in 3.1. During these test the GPR payload was not installed

as the SCADA server was still being developed. Without the operation of the SCADA

the Noggin could not be deployed and so early testing of the survey controller focused on

the partitioning of the scan area and the ability for the rovers to navigate the necessary

course.


Figure 5.3: The Musketeer’s experimental area.

Having demonstrated the Musketeers capability of accurately traversing the GPR sur-

vey, work was begun on the driver for the GPR unit. This software made use of a

dynamic-link-library (DLL) provided by Sensors & Software to give the Noggin basic

commands. To speed up development on this portion of the GPR project, the initial

version of GPRSurvey.exe directly implemented the DLL instead of using the ArgoSoft

client/server framework from Section 3.5. After the Sudbury integration test the conven-

tional ArgoServer and client framework was used to wrap around Sensors & Software’s

DLL, thus harmonizing the GPR with the other on-board sensors. Shortly after basic

communication was established with the Noggin the first successful GPR survey acquisi-

tion was made. Figure 5.5 shows the subsurface model generated by Xiphos for this data

set. While at a low resolution of 8m× 6m with 2m line spacing and 0.5m trace spacing,

this represent a successful demonstration of the full system capability. It was during this

preliminary testing phase that the problem with the GPR sleigh keeping contact with

the ground was noticed, and this necessitated the modification to the sleigh as mentioned

in Section 2.3.


Figure 5.4: Trajectories from early waypoint tracking software.

Initial testing focused on low-resolution, single rover tests to ensure that all hardware

interfacing as described by Chapters 2 and 3 was fully functional. Initial surveys were

completed in survey modes 2 and 4 (Chapter 3.1), however at the request of XTI they

were subsequently only acquired in modes 1 or 2, and eventually only in mode 1. Soon

into the development process UTIAS had a fully functioning system capable of providing

surveys which complied with every aspect of XTI’s “ISRU GPR Server ICD.”[Caillibot

& Sado 2009a] Before the integration of the Trimble GPS unit surveys generated were

as large as 25m× 25m, scanned at 2.5m line spacing and 0.1m trace spacing. The single

rover full-scale test took about 90 minutes to complete not including start up time of

approximately an hour. We reasoned that the full resolution test should have 5 times as

many lines, and move at approximately one third the speed to acquire traces at a higher

resolution. This yields an expected full test time of 23 operational hours. Distributed

amongst three rovers the full task was determined to take approximately eight hours to

complete.

For all testing activities Universal Transverse Mercator (UTM) coordinates were used

to gather data from both primary and secondary localisation devices. These are given


Figure 5.5: Although a low resolution scan, this 8m×6m model is evidence of a successful

autonomous acquisition of GPR data

as metres east and north of the centre of the particular grid as given by Figure 5.6.

Zone 17T (Toronto and Sudbury) and 5Q (Hawaii) are highlighted. These values are

converted to local Cartesian coordinates centered on a defined origin somewhere in the

area of operation.

During in-house testing it was observed that the IMU could be perturbed by the other

devices in the MIB and in fact from the chassis of the rover itself. For this reason a small

mast was built to extend out of the container for the MIB and MCB. An environmentally

shielded plastic casing was mounted on this mast to house the IMU, and was elevated

high enough to be outside of the area affected by the rover and its electronics. The mast

was also used to mount the antenna for the Trimble GPS unit to give it a clear line of

sight to satellites in any possible direction.


Figure 5.6: The grids of the Universal Transverse Mercator coordinate system.

Two thermal issues were also uncovered during in-house testing. Full scale GPR tests

were the first time the rovers were continuously operated for several hours. The combina-

tion of the summer heat of < 30◦ and the black, insulating MCB caused the temperature

of the MCC to exceed 60◦. This was high enough to trigger a thermal shut down of

the MCC, completely ruining any experimental results. The MCC was tested to handle

thermal stress however the operating temperature inside the MCB exceeded the tem-

peratures the MCC was subjected to during testing. This failure crippled testing many

times and was the initial motivation for incorporating the pause/resume feature of GPR

surveying. The rovers were operated with the MCCs mounted on small fans temporarily

while large heat sinks were manufactured. These required cutting a large portion of the

face of the MCB out to accommodate a heat sink with a large enough surface to cover

the entire MCC. Figure 2.16 shows the MCC resting on the large metal heat sink.

Since the GPR activities are relatively low impact on the motors when compared with

excavation, thermal issues in the motors were not immediately apparent. However it was


learned after the Sudbury integration test that the motors chosen by NORCAT were not

rated for continuous operation. Thus they were not designed to evacuate excess heat, and

would consistently overheat during any extended operation. This condition continued to

stress the motors and was responsible for their slow decay. Once excavation experiments

begun this problem quickly became obvious and thermal sensors were installed to prevent

damage to the motors. One sensor was installed on each the port and starboard motor,

one to measure the ambient temperature, and a fourth to measure the temperature in the

MIB. A high priority control module was then developed to monitor the temperatures

of the motors constantly, and in the case that an overheat threshold is reached, all

commands to the motors are overridden and the rovers come to a stop until the motors

cool to an acceptable temperature.

The ability to pause and resume surveys ended up being a critical development, nec-

essary for two reasons: battery change-out and system failures. With an expected task

time of 8 hours the charging of the rovers is inevitable. This requires a full power down of

the rover as well as the MCC and thus the resume functionality is a necessity. With any

testing there is likely to be some minor software failures such as a servers timing out and

unexpectedly closing. This should be a surmountable problem, alleviated by pausing the

survey and resuming once the issue has been addressed. To include this ability the GPR

controllers were altered so that MCC continuously uploaded data to the GCS during the

survey as opposed to at the completion of the individual rover’s subsection.

The first multiagent test was completed in Sudbury, shortly before the Trimble GPS

units were fully developed however it was completed under strict human supervision. The

primary localization device was not finally chosen until late into the rover development,

and the secondary localization did not provide sufficiently accurate position estimates to

permit MAT. The U-Blox GPS accuracy can often be worse than 10m in which case the

risk of collision is too great and it becomes hazardous to run multiple rovers on the same


test site. For this reason multiagent testing did not begin until after Sudbury testing

using the Trimble, with the exception of the single test at Sudbury.

After the Sudbury deployment the Trimble unit was used and the accuracy of positional

data was drastically improved. It was found to be so improved that the original driving

algorithm was no longer sufficient. While retuning the controllers allowed the algorithm

to get the rovers within approximately 3m of the intended goal, the bearing-aligned

control did not function properly as the distance scales approached the size of the rover

itself. The code used for driving was written to take into account both final position

and orientation in the trajectory so that only minor adjustments need to be made to

rotate the rover into the correct orientation. The details of this controller are discussed

in Gammell [2010].

A major improvement was made to the trace controller in the period between the

Sudbury and Hawaii deployments. To ensure traces are always being gathered as close to

the intended point as possible, a high trace acquisition speed is desired. If the acquisition

rate is too slow, when the rover gets to the next trace location, a trace will not yet have

been acquired and thus the NIC’s buffer will be empty. Conversely, if the trace acquisition

speed it too high, when the rover reaches the next location, the buffer will have too many

traces and it will take up a significant amount of CPU time to parse through the data. In

fact, often it is the case that when the acquisition rate is too great, the CPU usage is so

high that by the time the MCC has queried the encoders to read how far it has travelled,

the rover has already passed the next trace location. Since it is always necessary to

get a trace at the proper location it is better to err on the side of higher acquisition

speed. However, this can cause the performance problem described above. Previously,

as a solution to this, the rover simply had to be slowed down so that the CPU would

certainly have finished processing the data before the next location was reached. After the

Sudbury test the trace controller was upgraded to help deal with excess traces. Originally


the controller would check to see how far it has travelled, and if it had hit the next trace

location it would unload the buffer and find the proper trace. As a way to start getting

rid of unnecessary traces earlier, the improved trace controller collects all the traces off

the buffer every time the CPU is active on the trace control thread. In this way the

buffer data is processed constantly as the rover progresses between traces, as opposed to

all at once when a trace is requested. If traces are not required at any time, the buffer

data is simply discarded in its entirety, and thus a much smaller subset of data actually

has to be parsed and saved.

To validate the data being generated by the rovers, a Noggin was rented with the

accompanying manual survey cart. This was used to conduct a manual survey prior

to the Sudbury integration test. This scan was over an area for which a 25m × 25m

single-rover scan at 2.5m line spacing had already been provided to Xiphos. However,

no comparison between the autonomous and manually acquired scan was ever seen by

UTIAS, and it is thus impossible to relate how well the MAT performed as compared

to a standard human operator. To gauge the repeatability of the process, prior to the

Hawaii deployment two scans were taken of an identical 25m × 25m area. Both scans

used multiple rovers and were done with 0.5m line spacing.

5.2 Sudbury Integration Test

The goal of this activity was to collect GPR data for the site verification activity using

the Musketeers with the focus on demonstrating the seamless integration of the various

components of the mission. This was the first opportunity for the TriDAR, HPC, and

Musketeer team to interact through a single LAN as is intended for the final field-test.

Although the high-accuracy primary localisation devices were not yet integrated into the

rovers, a full three rover scan was attempted with heightened human supervision. This

was the first attempt at a multirover scan, and to avoid any possible collisions the GCS


operators were in direct radio contact with several spotters at the site. The only issue

which occurred was an IMU calibration error which delayed one of the three rovers while

the GCS operators resolved the issue. After this test recalibrating the IMU became a

regular start-up procedure for all rovers. In spite of the delay, a full 25m× 25m site was

surveyed using the three rover team with Neptec, Xiphos and UTIAS systems all working

in harmony. Although there was significant human supervision, with the exception the

IMU issue described above, there was no human interference or assistance during the

acquisition of the data. Thus the GPR capability of the rovers had essentially been

demonstrated in full autonomy. Although the subsurface map generated was not given

to UTIAS, the GPS data from the rovers during the test can be seen in Figure 5.7.

This figure shows data from a test scan using three separate rovers at Ethier. The x-

coordinate has been artificially fixed for each line to allow them to be distinguished. The

GPS locations are very inconsistent, an indicator of the poor GPS performance during

the adverse conditions in Sudbury. Without artificially fixing the x locations the data is

hardly distinguishable from a cloud of points. In subsequent surveys using the Trimble

the trace coordinates are much more evenly distributed along the scan lanes, as opposed

to the clumping seen in Figure 5.7.

Because the payload changeout procedure from GPR to blade was done in series, there

was additional time on the last rover before the GPR was to be changed out, even given

the delay due to IMU calibration. For this reason there was an opportunity to complete

a faster, lower-resolution scan using only one rover. Seven out of the total 11 scan lines

were completed before the GPR actuator reference voltages were shifted. This disrupted

the calibration done for the PID controller and the controller was trying to drive the

piston past its hardstop. This necessitated terminating the scan while the problem was

investigated. Although the scan wasn’t finished, Xiphos was still able to use the seven

scan lines to produce a subsurface map for the 15m× 25m area. The issue which caused


Figure 5.7: Trace locations from a 25m × 25m survey with 2.5m line spacing and 0.1m

trace spacing.

this hardware malfunction was determined to be from a floating voltage in the SCADA

distribution box. This was fixed by making adjustments to the power distribution circuit

in the SCADA housing.

In addition to the 25m × 25m and 15m × 25m scans provided by the Musketeers, a

manually survey was conducted over the same 25m × 25m area using rented hardware.

All three of these surveys were used to construct 3D models of the subsurface, however

the results were not sent to UTIAS so it is not possible to reflect on the quality of the data

either in terms of repeatability or accuracy with respect to ground truthing. Figure 5.8

shows a Musketeer with the excavation payload at the site of the GPR scans. Close

inspection of the photo reveals the lines created in the ground cause by dragging the

GPR unit along the ground.

5.3 Hawaii Field Test

In Hawaii the objective was to perform a full system deployment, and thus very little

development took place on-site. For the GPR survey the only aspects which needed


Figure 5.8: A rover equipped with a blade payload in the field during Sudbury integration

testing

testing were the V1 and V2 versions of the line controller (Chapter 3.2). While V1 was

fully demonstrated, there was unfortunately not enough time to fully debug V2. This is

something that should be able to be completed in a short amount of time, and would

likely improve the performance of the MAT GPR survey. More discussion is given on

this point in Chapter 6.

The basic layout of the test site located at 9000ft on the slopes of Mauna Kea is

shown in Figure 5.10. The GPR scan took place over the area defined by the red square

around ‘Landing Pad Construction Experiment.’ Three days were allotted for the GPR

activities. The first day consisted of acquiring a manual survey to ground truth the data

acquired by the Musketeer team. Prior to the Hawaii departure two basic test plans were

established for the two test days allocated to MAT GPR acquisition. GPR-1 and GPR-2


Figure 5.9: Two rovers acquiring GPR data in Hawaii.

are the names of the test plans and are both based and the following procedure:

1. Execute boot-up procedure for each rover involved (see Appendix)

2. Obtain coordinates for survey site

3. Teleoperate the rovers to the survey site

4. Test resolution parameters by acquiring a single scan line (Menu Option 2 in

GPRSurvey.exe) confirming that the selected rover speed and trace acquisition

speed permit the desired resolution

5. Begin survey configuration (Menu Option 3)

6. Input site coordinates

7. Input resolution parameters (line spacing = 2.5m, trace spacing = 0.02m)

8. Use GPRSurvey to assign a specified portion of the survey to each rover


Figure 5.10: Site plan for Hawaii Experiment GCS and GSS located in red tents near

origin. Note that road was constructed to the south of the landing pad instead.

9. Commence the survey

10. As the survey progresses confirm that all rovers are in the same stage (beginning

line, driving to next line) before allowing them to continue

11. When the survey is completed, compile all GPR data on GCS

12. Append a .top file generated by from GPRSurvey.exe

13. Compress data using bsdtar.exe

14. Move survey file to GCS HTTP Server

15. Files are unpacked and inspected by Xiphos on the HPC

16. 3-D Subsurface map is generated by Xiphos

The above is a copy of the text from GPR-2. GPR-1 differs only in that the trace-

spacing is 0.05m. Instead of attempting to acquire a single larger survey over the two


Table 5.1: Parameters used for final testing.

Field Description GPR-1 GPR-2

Survey Site Corners GPS coordinates defining the survey region, given in local Cartesian (m) (20,17), (32,40) (24,18), (32,30)

Rover Speed - Transit Speed at which the rovers transit to the next way-point (m/s) 0.5 0.5

Rover Speed - GPR Speed at which the rovers drive while acquiring traces (m/s) 0.08 0.12

Line Spacing Distance between successive scan lines (m) 0.5 0.5

Trace Spacing Distance between traces in a scan line (m) 0.1 0.1

Orientation Threshold How accurately the rover orients itself (rad)

Position Threshold How accurately the rover attempts to reach a way-point (m) 0.5 0.5

Trace Stacking Number of traces to collect and average at each point 8 8

Points Per Trace Number of data points in a trace 100 100

Trace Acquisition Rate How often the GPR gathers traces (Hz) 10 10

days, it was decided that two separate surveys may help to demonstrate the robustness

of the system, as well as providing two separate data sets with which to validate the

repeatability of the acquisition.

The trace-spacing was set higher in GPR-1 to allow the rover’s operational speed to

increase, thus speeding up the task. Once this was achieved it was hoped that a second

higher resolution scan could be completed over some subset of the original scan. The

plan was originally to acquire a full 25m × 25m survey in GPR-1. In the time allotted

for the task a full survey required 2.5m line-spacing. During on-site discussion this was

deemed too large. At a 2.5m line-spacing it is possible that a rock which is too large

for the rovers to move would be missed. Instead we chose to scan a smaller total survey

area but at a higher resolution. Due to the software improvement regarding the trace

controller discussed in Section 4.2.1, a five-fold increase in the line-spacing resolution

did not limit the survey area to one fifth the intended size. Being able to acquire scan

lines faster than originally thought allowed a 25m× 15m scan area to be attempted for

GPR-1 while using 0.5m line-spacing. GPR-2 was smaller as expected, and only having

the use of two rovers limited us to attempting to collect a 16m× 12m survey. The final

parameters used for the tests are outlined below in Table 5.1.


During GPR-1 there was a motor failure on Aramis. Unfortunately, this cost a lot

of time debugging trying to determine why the driving algorithms were not functioning

as expected. The GPR activity did not directly cause the failure, rather, an existing

condition on the motor from previous experiments finally caused the motor to become

completely unresponsive. The motor failure is discussed in greater detail in Section

6. Because of the failure one of the rovers had to be dropped from the survey. Thus

instead of acquiring the intended 15m× 25m scan, the two remaining rovers produced a

15m× 20m scan. The data for this survey was packaged up in a compressed archive and

posted to the GPR data server for Xiphos to use in constructing a subsurface model.

For GPR-2 the rover team was down to two rovers as one rover had to be used for the

Neptec and NORCAT ‘Load-Haul-Dump’ activity. The two rovers can be seen acquiring

the survey in Figure 5.11.

Figure 5.11: In this shot the path left by the GPR as it is dragged through the soil is

clearly visible.


The inability of the rover’s GPS units to acquire OMNISTAR lock results in a severe

degradation of the rovers functionality. In GPR-1, the progress of the survey was hindered

while waiting for OMNISTAR to lock back in after drop-outs. However in GPR-2 one

rover was completely unable to acquire an OMNISTAR lock and the rover’s inability to

properly localize itself clearly showed in the decreased performance. The GPS locking

problem is further discussed in Section 6. From the elevated view of Figure 5.12 it can be

seen that the data on the left was clearly not as evenly spaced or well aligned as the data

on the right. For this reason the decision was made to terminate the poorly performing

rover near the end of the scan and instead of a 16m × 12m scan, GPR-2 was only an

8m× 12m scan.

Figure 5.12: An elevated view of the site after the GPR scan.

Chapter 6

Results and Conclusions

Before discussing the results of the two surveys completed in Hawaii, it is important

to note that UTIAS is only able to evaluate our ability to provide Xiphos with GPR

data, and that we were not involved with the generation of the 3D models. Therefore the

actual quality of the data obtained is very difficult to validate here. Combined with the

fact that we don’t have the ground truthing model, our success can only be evaluated on

the acquisition process.

The first survey was completed with two rovers, as discussed in the previous section,

and the final file for GPR-1 was just under 4MB. Xiphos was able to gather the data

off of our GPR server and construct the 3D model shown in Figure 6.1. The majority

of the subsurface structures appear very thin. The reason for this is that there does not

seem to be a single instance where a particular object has spanned two scan lines. That

is, no object which was detected could be seen in two or more parallel lines. This does

not necessarily imply that there was no subsurface object larger than .5m as there are

two ways this scan could have missed an object larger than .5m. This is illustrated in

Figure 6.2 where the red object has missed detection altogether and the orange object

happens to be in a spot where it barely missed being detected two or even three times. An

improvement to the existing scanning technique which could help detect objects shown in

82

Chapter 6. Results and Conclusions 83

Figure 6.1: 3D model of GPR-1.

Figure 6.2 would be to use one of the bidirectional scanning modes discussed in Section

3.1. Presumably, the go-ahead on the site-selection decision was made on the grounds

that no object appeared in more than one scan line.

The only complaint from Xiphos regarding GPR-1 was that some of the scan lines were

not perfectly parallel, and in some cases they even crossed. This is particularly evident

in Figure 6.3 where it can be seen that the rover on the left had issues both with GPS

and initial IMU alignment. Since we were running V0 (Chapter 3.2) the initial alignment

problem was not corrected for. However it is clear that the rover on the right did much

better both in terms of GPS accuracy and IMU alignment.

Since we had already provided a survey, and had the majority of a day left to scan

we were able to finish debugging V1 for use in the next survey. Although only covering

a small area, GPR-2 represented a great improvement over GPR-1. The 3D subsurface

map can be seen in Figure 6.4 while the improvement in terms of line regularity is evident

in Figure 6.5.


Figure 6.2: Subsurface objects going unnoticed.

Figure 6.6 and Figure 6.7 demonstrate the relative locations of the two scans. This is

helpful as it allows some comparison of the subsurface structure so that it is possible to

visually characterize the repeatability of the acquisition process.

Finally, Figure 6.8 shows the final product of the site selection activity: a full map of

the experimental area including the subsurface. Although no quantitative analysis has

been done by UTIAS, Figure 6.9 is an attempt to pick out similar subsurface structures

identifiable in both surveys. In this figure the same structures have been pointed out with

one of three colors in both individual maps as well as the combined map. It is important to

note that this is purely for interest’s sake and in no way reflects any definitive detection

of the same object across multiple scans. Presumably some quantitative analysis was

conducted by XTI to establish the degree of similarity between the two scans.

The construction of the 3-D models was done exclusively by Xiphos, and the determi-

nation of whether or not the mission could proceed based on the combined surface and

subsurface map was done by Xiphos and NORCAT in conjunction with the CSA. Since

UTIAS had no involvement in the construction of the 3D models or in the analysis of the


Figure 6.3: Trace locations for GPR-1.

data or in the decision of whether or not to proceed with the excavation, the only thing

we are able to evaluate our success on is the ability of the Musketeers to autonomously

acquire a GPR survey. In this respect our mission to Hawaii was a success. While we

were unable to provide a 25m× 25m scan at a sufficiently high resolution, we were able

to do so on a smaller scale. Given more time there is no reason to suspect that the Mus-

keteers would be unable to acquire a larger scan. In fact UTIAS has provided Xiphos

with several full scale scans taken at the UTIAS testing area.

Rover failures did demonstrate the robust nature of MAT. While there were problems

with one rover in each of the scans, this is only disadvantageous in the amount of data we

were able to provide. In terms of the robustness of the system, this demonstrated one of

the key advantages of MAT. Even though one rover dropped out, the other rovers were

still able to complete their tasks, thus showing that MAT removes the single-point-failure

of individual rover systems.

Three significant problems did however cause some difficulty in the GPR activity.

First, it became clear that our GPS system was not an effective method of localization.

Since we were dependent on a third-party, when the units lost their accuracy there was


Figure 6.4: 3D model for GPR-2.

nothing that could be done on-site except to wait. While the GPS units have very good

accuracy when OMNISTAR is active, they are reduced to consumer-grade GPS units

without it. For this reason it would have been a much better decision to have gone with

a stand-alone option that could have had an on-site solution.

Second, the motors were not adequate for the task. While the GPR did not cause a

failure in the motors, a lingering effect from earlier testing that had been hampering the

motor’s performance caused the motor to finally cease working entirely. Unfortunately,

the thermal monitors failed during the final few hours before the motor had completely

died, but what little thermal data is available is presented in Figure 6.10. Additionally,

Figure 6.11 and Figure 6.12 show the current drawn by each motor leading up to the

failure. From these figures it is evident that there was no sustained high-load driving

which would be able to cause the motor failure, further supporting the notion that the

damage had occurred previously and only fully manifested itself after further use.

The last significant obstacle was the jumping of the actuator references in the SCADA

system. Sometimes during the GPR activity the voltage references would change by a


Figure 6.5: Trace locations for GPR-2.

few volts, causing the SCADA server to think the actuator is in a position that it is not.

Because of this the actuator would keep driving as it approached the hardstops, at which

point it would clutch. To avoid damage, the SCADA server would have to be stopped,

then restarted until the voltages dropped back to the normal level. This was a problem

which was originally thought to have been resolved but was evidently not completely

dealt with.


Figure 6.6: The results of both GPR surveys overlaid.

Figure 6.7: Coordinates for Trace Locations; GPR-1 in Blue and GPR-2 in Red


Figure 6.8: A combined surface and subsurface map showing the entire working area.


Figure 6.9: The results of the surveys are compared to visually highlight similarities. This

is simply done by eye and has no bearing on any quantitative assessment of similarity.


Figure 6.10: Temperature Log for Aramis Before Motor Failure

Figure 6.11: Motor Current Logs for Aramis Before Motor Failure


Figure 6.12: Motor Currents for Aramis Starting 2.5 Hours Prior to Failure

Chapter 7

Closing Thoughts and Future Work

While many strides have been made, there is much work to be done on the concept of

autonomous GPR acquisition for space robotics. In particular, it would be desirable to

finish debugging/testing GPR V2 for improved results. V1 has been demonstrated to be

working effectively as in Figure 7.1. It is felt that V2, with minimal work would be fully

functioning and would allow the Musketeer GPR activity to produce even better results.

A second, minor improvement that could be made is a slight increase in accuracy of the

trace position by updating the trace controller. As the trace controller checks the rover’s

distance and decides when to save a trace, it very rarely will query the encoder at exactly

the correct distance. By knowing the distance traveled since the last time the buffer was

cleared, it would be possible to estimate exactly where each trace was taken. Thus it may

be possible, that instead of taking the most recently acquired trace the controller could

infer which trace stored in the buffer is closest to the actual position. While the noise in

the encoders and the GPS may be large enough to make this improvement negligible, it

is nevertheless useful to implement.

93

Chapter 7. Closing Thoughts and Future Work 94

Figure 7.1: Demonstration of V1 Correcting Initial Orientation Errors (Highlighted by

Yellow Arrows)

For future GPR surveys there are two major recommendations. First, using a bidi-

rectional scan (combine two surveys of one area, with the second survey having scan

lines perpendicular to the first) would be a significant improvement. This helps detect

obstacles such as in Figure 6.2, particularly the red object. In addition, it was made

clear at the GPR training session given by Sensors & Software, that the bidirectional

scan was the much preferred method as it was generally able to do a much better job

in resolving subsurface structures. The second recommendation is allotting much more

time to complete the GPR task. This would have alleviated much of our problems in

Hawaii since we did not have time to properly address problems as they came up, and

instead had to ’patch things up’ and move on.

Chapter 7. Closing Thoughts and Future Work 95

While there is much to be done before a final, space-ready deployment of GPR-

acquiring rovers, this research project has been very fruitful. A prototype for a modular

lunar rover has been effectively demonstrated as capable of completing several tasks,

and in particular, the gathering of GPR data. This dissertation also details an effective

method to control and coordinate a suite of sensors into a coherent electrical architec-

ture. A fully-automated control scheme was proven to be effective at controlling up to

three rovers and coordinating the autonomous acquisition of 3D GPR data. In addition

to the actual GPR survey controller, several other controllers were developed for basic

locomotion and hardware control. While there has been much work on GPR-applications

for autonomous robotics, this project represents the first autonomous acquisition of 3D

GPR data by a mobile robot. This is a significant contribution not only to space robotics,

but to robotic systems in general, and is a reminder of the ever-increasing abilities of

modern robotics.

In conclusion, this project was a success in that a completely autonomous mobile

platform was developed to acquire 3D data. Full GPR data sets were provided during

in-house testing, and given hardware failures, preformed as expected in Sudbury and

Hawaii. This contribution is further justification for investigating MAT as a robotics

strategy. Moreover, this project has demonstrated a high readiness level for a technology

of vital importance to ISRU. And lastly, this dissertation presents the results of the first

successful acquisition of 3D GPR data by an autonomous mobile platform.

Chapter 8

References

1. Barfoot T, D’Eleuterio G, Annan A, “Subsurface Surveying by a Rover Equipped

with Ground-Penetrating Radar,” IEEE/RSJ Internation Conference on Intelligent

Robotics and Systems, Las Vegas, 2003.

2. Beck R, Osborn J, “Three dimensional migration and forward modeling of ground

penetrating radar data,” Technical Report CMU-RI-TR-91-12, Robotics Institute,

Carnegie Mellon University, Pittsburgh, PA, June 1991.

3. Beyer L, “Lunarcrete - A Novel Approach to Extraterrestrial Construction,” Pro-

ceedings of the Seventh Princeton/AIAA/SSI Conference, 1985, pp. 172.

4. Caillibot E, Sado M, “ISRU GPR Server ICD,” XTI Document No. XTI-1176-1041,

2009a.

5. Caillibot E, Sado M, “ISRU Operational Capabilities Site Verication Test Plan,”

Xiphos Document XTI- 1176-1064-a, 2009b.

6. Cutler A, Krag P, “A Carbothermal Scheme for Lunar Oxygen Production,” P.Lunar

Bases and Space Activities of the 21st Century. Houston, 1985, pp. 559 1985.

7. Duke M, Blair B, Diaz J, “Lunar Resource Utilization,” Advanced Space Research,

Vol.31, 2002, pp. 2413.

8. Fong T, Allan M, Bouyssounouse X, Bualat M, Deans M, Edwards L, Flckiger L,

96

Chapter 8. References 97

Keely L, Lee S, Lees D, To V, Utz H, “Robotic Site Survey at Haughton Crater,”

9th International Symposium on Artificial Intelligence, Robotics and Automation

in Space, Los Angeles, 2008.

9. Fox R, Schowengerdt F, Duke M, Ignatiev A, Abbud-Madrid A, “A Multi-disciplinary

Approach to the Most Multi-disciplinary of Problems: A Sustained Extraterrestrial

Human Presence,” NLSI Lunar Science Conference, 2008.

10. Furgale P, Barfoot T, Ghafoor N, “Rover-Based Surface and Subsurface Modeling

for Planetary Exploration,” In Proceedings of Field and Service Robotics, 2009.

11. Gammell J, “Evaluation of on Autonomous Mobile Platform for Proof-of-Concept

Site Selection and Preparation for In-Situ Resource Utilization,” UTIAS MASc

Thesis, 2010.

12. Gamsky J, Metzger P, “The Physical State of Lunar Soil in the Permanently Shad-

owed Craters of the Moon,” Earth and Space 2010: Engineering, Science, Con-

struction, and Operations in Challenging Environments, 2010.

13. Groenenboom J, van der Kruk J, Zeeman J, “3D GPR Data Acquisition and the

Influence of Positioning Errors on Image Quality,” EAGE 63rd Conference and

Technical Exhibition, Amsterdam, 2001.

14. Herman H, “Robotic Subsurface Mapping Using Ground Penetrating Radar,” doc-

toral dissertation, tech. report CMU-RI-TR-97-19, Robotics Institute, Carnegie

Mellon University, 1997

15. Kohout T, O’Sullivan K, Losiak A, Kring D, Thaisen K, Weider S, “Robotic and Hu-

man Exploration of the Schrodinger Basin,” Joint Annual Meeting of LEAGICEUM-

SRR(LPI Contributon No. 1446). Vol 1446, 2009.

16. Maniscalco M, Lee N, Dektor S, Salowitz N, Grote E, Twiggs R, “A Design Con-

cept for a Robotic Lunar Regolith Harvesting System,” ICRA ’07 Space Robotics

Workshop, 2007.


17. Metzger P, Immer C, Lane J, Smith J, Studak J, Banker B, “Rocket Plume Imping-

ment on Mauna Kea Lunar Analog Site Compared with Photogrammetry of Apollo

Lunar Landing Videos,” Space Resources Roundtable XI / Planetary & Terrestrial

Mining Sciences Symposium, 2010.

18. Motoyuki S, Kobayashi T, Takahashi K, Fujiwara J, Feng X, “Vehicle-mounted

SAR-GPR and its evaluation,” Proc. SPIE 6217, 2006.

19. Najjaran H, Goldenberg A, “Landmine Detection using an Autonomous Terrain-

Scanning Robot,” NRCC-46424, National Research Council Canada, 2005.

20. Navish F, May M, “Autonomous Mine Detection Sensors,” Proc. SPIE 6217, 2006.

21. Nozette S, Lichtenberg C, Spudis P, Bonner R, Ort W, Malaret E, Robinson M,

Shoemaker E, “The Clementine Bistatic Radar Experiment,” Science 29, Vol. 274,

1996, pp. 1495-1498.

22. Rapp D, “Fueling of Mars-Bound Vehicles in LEO with Propellants Derived from

Lunar Resources”, Skillstorm, Inc. in affiliation with JPL, April 2005.

23. Sanders G, Duke M, “NASA In-Situ Resource Utilization Capabilities Roadmap,”

2005.

24. Sanders G, Larson B, Sacksteder K, Mclemore C, Jonson K, “Lunar In-Situ Re-

source Utilization: Development and Implementation,” 2007.

25. Schmidt S, Boucher D, McTaggart M, “Analogue Deployment Management,” Space

Resources Roundtable XI / Planetary & Terrestrial Mining Sciences Symposium,

2010.

26. Slob E, Groenenboom J, Fokkema J, “Automated Acquisition and Processing of

3D GPR Data for Object Detection and Characterization,” Subsurface Sensing

Technologies and Applications Volume 4, Number 1, 2003.

27. Stentz A, Bares J, Singh S, Rowe P, “A Robotic Excavator for Autonomous Truck

Loading,” in proceedings of IEEE/RSJ International Conference on Intelligent


Robotic Systems, Washington DC, 1998.

28. Taylor L, Carrier W, “Oxygen Production on the Moon: An Overview and Evalu-

ation,” Resources of Near Earth Space, U. Arizona Press, Tucson AZ, 1993.

29. Thangavelautham J, Smith A, Boucher D, Richard J, D’Eleuterio G, “Application

of an Artificial Neural Tissue Controller to Multirobot Lunar ISRU Operations”

Proceedings of Space Technology and Applications International Forum, 2007.

30. Thangavelautham J, Smith A, Abu El Samid N, Ho A, Boucher D, Richard J,

D’Eleuterio G, “Multirobot Lunar Excavation and ISRU Using Artificial-Neural-

Tissue Controllers,” Proceedings of the Space Technology and Applications Inter-

national Forum 2008.

31. Vago J, Gardini B, Kminek G, Baglioni P, Gianfiglio G, Santovincenzo A, Bayon

S, van Winnendael M, “ExoMars - searching for life on the Red Planet,” ESA Bull.

126, 2006.

32. Whittaker W, Skonieczny K, DiGioia M, Wettergreen D, “Configuring innovative

regolith moving techniques for lunar outposts,” U.S. Chamber of Commerce Pro-

grammatic Workshop on NASA Lunar Surface Systems Concepts, 2009.

Documents

Acquisition of 3D Ground-Penetrating Radar Data by an ... · This dissertation details the design and development of a mobile autonomous platform from which to conduct a 3D ground-penetrating