seseWORCESTER POLYTECHNIC INSTITUTE Computer Science, … · 2020. 5. 18. · NASA Lunabotics 2019-2020 A Major Qualifying Project submitted to the Faculty of WORCESTER POLYTECHNIC

seseWORCESTER POLYTECHNIC INSTITUTE

Computer Science, Mechanical Engineering,

And Robotics Engineering Programs

NASA Lunabotics 2019-2020

A Major Qualifying Project

submitted to the Faculty of

WORCESTER POLYTECHNIC INSTITUTE

In partial fulfillment of the requirements for the Degree in Bachelor of Science by:

Kevin Bimonte, Computer Science

Harrison Burack, Computer Science

Cara Freedman, Mechanical Engineering

Jack Hogan, Computer Science

Mark Hogan, Robotics Engineering

Nicole Kuberka, Robotics Engineering

Project Advisors:

Professor Nicholas Bertozzi

Professor Joshua Cuneo

Professor Therese Smith

Date: 05/18/2020

This report represents the work of WPI undergraduate students submitted to the faculty as

evidence of a degree requirement WPI routinely publishes these reports on its website without

editorial or peer review. For more information about the project’s program at WPI, see

https://www.wpi.edu/project-based-learning

https://www.wpi.edu/project-based-learning

i

Abstract

This paper reviews the entire design process, from conceptual development to final product, of an

autonomous mining robot designed to meet the specifications of the 2020 NASA Robotic Mining

Competition. The need for on planet autonomous resource collection is growing as NASA prepares

for its Artemis program, a mission designed to establish a sustainable habitat on the moon. The

rover is designed to navigate in a moon simulated environment, dig and return a payload, as well

as meet the constraints imposed by the unique operating environment. This document addresses

the engineering challenges and goals that were faced, ranging from communication, obstacle

avoidance to heat management. Finally, this robot and the research behind it lay the groundwork

upon which future teams may build.

ii

Acknowledgments

Our team wishes to thank various WPI faculty for their assistance in this project. Holly Ault

provided her remote assistance in the mechanical team's shift of focus from building the robot to

further virtual design development using SolidWorks. She showed different analysis methods on

finalized robot designs and gave insight on techniques to improve current models. Mike Ciaraldi

gave our team valuable information regarding the methods of communication and visualization of

the environment. As a previous Computer Science advisor for WPI’s NASA Robotics Challenge

team, he provided valuable input regarding the competition field, allowing for a more refined

method of visualization. Fred Looft gave us valuable insight and taught us how to create a basic

system engineering paper while also providing ideas on how to improve teamwork and overall

team. Lastly, Ken Stafford provided excellent support to the mechanical aspects of the robot. He

assisted with forming proper models and diagrams for calculations, as well as the

recommendations for the robot from past experiences. His knowledge in both Robotic Engineering

and the Robotic Mining Competition has provided our team with the support necessary to complete

this project.

iii

Authorship

Abstract JH, NK, KB, edited by CF, HB, MH

Authorship HB, CF, NK, edited by KB, MH, JH

1. Introduction JH, KB, MH, edited by HB, JH, CF

2.1. NASA Robotic Mining Competition MH, JH, HB, edited by KB, CF

2.2. Previous WPI Entries HB, KB, NK, edited by JG, HB, CF

Software KB, edited by JH, HB, CF

Past Strengths and Weaknesses NK, KB, edited by HB, JH, CF

2.3. Mars JH, NK, edited by KB, MH, CF

Martian Atmosphere JH, HB, edited by KB, MH, CF

Operational Challenges JH, NK, edited KB, MH, CF

3. 2020 RMC: Lunabotics HB, MH, KB, edited by NK, JH, CF

3.1. Current Rules and Restrictions MH, edited by NK, JH, JB

3.2. Robot Deliverables NK, MH, edited by JH, HB, CF

3.3. System Requirements Review NK, CF, edited by JH, HB, CF

4.1. Mechanical MH, CF, NK, edited by HB, KB, JH

Excavation Designs CF, MH, edited by NK, JH, CF

Auger CF, NK, edited by MH, JH, HB

Bucket Wheel CF, MH, NK edited by JH, HB

Conveyor CF, MH, NK, edited by MH, NK, JH

Wheels vs. Treads MH, NK, CF, edited by MH, JG, CF

Linkage CF, edited by NK, MH

iv

Base MH, CF, edited by NK, CF, JH

Passive Lift Containment NK, CF, edited by CF, MH, JH

Final CAD CF, MH, KB, edited by NK, JH

Mass Budget NK, edited by NK, JH, CF

4.2. Electronics NK, edited by HB, JH, MH

4.3. Software HB, KB, JH, edited by JH, NK, MH

ROS2 JH, KB, edited by HB, CF, MH

Actions JH, KB, edited by CF, NK, MH

ROS 1 vs ROS 2 JH, KB, edited by HB, CF, MH

Raspberry Pi 4 JH, HB, edited by HB, MH, CF

Teleoperations vs Autonomy HB, KB, JH, edited by KB, JH, NK

Sequence Methodologies JH, KB, HB, edited by CF, KB

Vision and Navigation HB, JH, edited by CF, NK, MH

NVIDIA Jetson HB, MH, edited by KB, JH, CF

Intel RealSense HB, edited by KB, JH, CF

Simultaneous Location and Mapping KB, JH, edited by HB, MH, CF

OpenVSLAM and OpenCV KB, JH, HB, edited by NK, MH, CF

Communication HB, edited by NK, MH, CF

HERO Development Board HB, KB, edited by KB, HB, CF

IMU HB, edited by NK, MH, KB

Ethernet KB, edited by HB, MH

Database KB, NK, edited by HB, JH, MH

v

Component Relationships KB, edited by HB, JH, MH

Subsystems KB, edited by HB, JH, MH

Trials KB, NK, edited by HB, JH, MH

Message Relationships KB, edited by HB, JH, MH

5.1. Development and Prototyping CF, MH, NK, edited by MH

5.2. Sinkage Calculations NK, MH, edited by HB, CF, MH

5.3. Speed Calculations MH, edited by NK, CF

5.4. Drive Base Calculations MH, CF, edited by CF, NK

5.5. Four-Bar Static Analysis CF, edited by MH, NK

5.6. Four-Bar Motion Studies CF, NK, edited by HB, CF

5.7. Digging Bucket Static Analysis CF, edited by NK, CF

5.8. Passive Conveyor Lift Calculations NK, MH, edited by MH, KB, CF

5.9. Material Collection Calculations CF, NK, edited by MH, HB

5.10. Power Consumption NK, edited by HB, MH, CF

5.11. Heat Dissipation JH, CF, edited by HB, NK, MH

5.12. Database Size KB, edited by HB, NK, MH

5.13. Risk Mitigation NK, edited by HB, MH, CF

5.14. Validation Testing NK, MH, edited by HB, MH, CF

6.1. Scrum MH, HB, edited by KB, CF

6.2. Product Breakdown System (PBS) KB, NK, MH, edited by CF, HB, KB

6.3. Cost Plan MH, NK, edited by HB, CF, KB

7. Social Implications MH, edited by HB, CF, KB

vi

7.1. Renewable Energy Sources MH, edited by HB, CF, KB

Regolith as Fuel MH, edited by HB, CF, KB

Additional Sources MH, edited by HB, CF, KB

8. Conclusion CF, HB, MH, edited by JH, NK, KB

8.1. Future Work NK, MH, HB, edited by KB, CF

Appendix A. Lunabotics Awards MH, edited by NK, HB, KB

Appendix B. Sketches MH, KB, edited by CF

Appendix C. Sinkage Calculations NK, edited by MH, CF

Appendix D. Four Bar Calculations CF, edited by MH, NK

Appendix E. Bucket Free Body Diagram Results CF, edited by MH, NK

Appendix F. Sequence Diagrams JH, HB, KB, edited by JH, HB, KB

vii

Contents

Abstract ...................................................................................................................................... i

Acknowledgments ...................................................................................................................... ii

Authorship ................................................................................................................................ iii

Contents ................................................................................................................................... vii

Equations ....................................................................................................................................x

Figures ...................................................................................................................................... xi

Tables ..................................................................................................................................... xiii

Introduction .............................................................................................................................1

Background .............................................................................................................................3

NASA Robotic Mining Competition .................................................................................3

Previous WPI Entries .......................................................................................................4

Software ..............................................................................................................................4

Past Strengths and Weaknesses ............................................................................................4

Mars .................................................................................................................................6

Martian Atmosphere ............................................................................................................6

Operational Challenges ........................................................................................................9

2020 RMC: Lunabotics ......................................................................................................... 10

Current Rules and Restrictions ....................................................................................... 11

Robot Deliverables ......................................................................................................... 12

System Requirements Review ........................................................................................ 13

Design ................................................................................................................................... 16

Mechanical ..................................................................................................................... 16

Excavation Designs ........................................................................................................... 17

Auger ............................................................................................................................ 17

Bucket Wheel ................................................................................................................ 19

Conveyor ....................................................................................................................... 21

Wheels vs. Treads.............................................................................................................. 22

Linkage ............................................................................................................................. 24

Base .................................................................................................................................. 24

Passive Lift Containment ................................................................................................... 27

Final CAD ......................................................................................................................... 29

Mass Budget ...................................................................................................................... 31

viii

Electronics...................................................................................................................... 32

Software ......................................................................................................................... 34

ROS2 ................................................................................................................................ 34

Actions .......................................................................................................................... 37

ROS 1 vs ROS 2 ............................................................................................................ 38

Raspberry Pi 4 ............................................................................................................... 38

Teleoperations vs Autonomy ............................................................................................. 39

Sequence Methodologies ................................................................................................... 40

Vision and Navigation ....................................................................................................... 40

NVIDIA Jetson .............................................................................................................. 41

Intel RealSense .............................................................................................................. 41

Simultaneous Location and Mapping ............................................................................. 42

OpenVSLAM and OpenCV ........................................................................................... 43

Communication ................................................................................................................. 45

HERO Development Board ........................................................................................... 45

IMU .............................................................................................................................. 46

Ethernet ......................................................................................................................... 47

Database ............................................................................................................................ 47

Component Relationships .............................................................................................. 49

Subsystems .................................................................................................................... 50

Trials ............................................................................................................................. 50

Message Relationships................................................................................................... 52

Analysis ................................................................................................................................ 54

Development and Prototyping ........................................................................................ 54

Sinkage Calculations ...................................................................................................... 58

Speed Calculations ......................................................................................................... 59

Drive Base Calculations ................................................................................................. 60

Four-Bar Static Analysis................................................................................................. 63

Four-Bar Motion Studies ................................................................................................ 67

Digging Bucket Static Analysis ...................................................................................... 68

Passive Conveyor Lift Calculations ................................................................................ 72

Material Collection Calculations ..................................................................................... 73

Power Consumption ..................................................................................................... 73

ix

Heat Dissipation ........................................................................................................... 75

Database Size ............................................................................................................... 77

Risk Mitigation ............................................................................................................. 78

Validation Testing ........................................................................................................ 80

Project Organization .............................................................................................................. 82

Scrum ............................................................................................................................. 82

Product Breakdown System (PBS).................................................................................. 83

Cost Plan ........................................................................................................................ 83

Social Implications ................................................................................................................ 87

Renewable Energy Sources............................................................................................. 87

Regolith as Fuel ................................................................................................................. 87

Additional Sources ............................................................................................................ 90

Conclusion ............................................................................................................................ 92

Future Work ................................................................................................................... 93

Bibliography ............................................................................................................................. 95

Appendices ............................................................................................................................. 103

Appendix A. Lunabotics Awards ......................................................................................... 103

Appendix B. Sketches ......................................................................................................... 106

Appendix C. Sinkage Calculations ...................................................................................... 110

Appendix D. Four Bar Calculations ..................................................................................... 111

Appendix E. Bucket Free Body Diagram Results ................................................................ 112

Appendix F. Sequence Diagrams ......................................................................................... 112

x

Equations

Equation 1. The probabilistic law characterizing the evolution state (Mahroos, Hassan, & Shaaban,

2011) ........................................................................................................................................ 42 Equation 2. Determining the distance taken based on Figure 38................................................. 60

Equation 3. Velocity required to complete the longest path in 5 minutes ................................... 60 Equation 4. Torque required for drive base motor ..................................................................... 60

Equation 5. Calculation of resultant friction force, assuming no resistant force (Fr) ................... 63 Equation 6. Force required for the passive piston to life the deposite conveyor. ......................... 73

Equation 7. Goal Heat Resistance of the System........................................................................ 76 Equation 8. Thermal Resistance from Conduction ..................................................................... 76

Equation 9. Equation to figure out size of row. .......................................................................... 77 Equation 10. Bekker Pressure-Sinkage Equation ..................................................................... 110

Equation 11. Recce Pressure-Sinkage Equation ....................................................................... 110

xi

Figures

Figure 1. NASA’s Lunabotics Logo ............................................................................................3

Figure 2. Markhor .......................................................................................................................5 Figure 3. The five most abundant gasses in the Martian atmosphere plotted logarithmically

(Dunbar & Greicius, The Five Most Abundant Gases in the Martian Atmosphere, 2012) ............6 Figure 4. The solar wind (beige streaks) rips molecules from Mars’ atmosphere. Orange lines

represent high energies of outgoing ions, blue low (Shirah, 2015) ..............................................7 Figure 5. A smooth curve of atmospheric pressure along with the same time frame. ....................8

Figure 6. Icy Regolith simulant (gravel), at various sizes (Heiney & Johanboeke, RMC Icy-

Regolith Simulant, 2018) .......................................................................................................... 10

Figure 7. Sketch of proposed digging mechanism, showing the internal chamber (top right), and

the outer drill shell opening to deposit material into the collection bin (bottom left). ................. 18

Figure 8. Excavator Wheel Assembly ........................................................................................ 19 Figure 9. Excavator Wheel Assembly expanded ........................................................................ 19

Figure 10. 3D-Printed guide for excavator wheel ....................................................................... 20 Figure 11. CAD model comparison of current LOADER bucket design (left) and the previous

year’s robot bucket design (right). ............................................................................................. 21 Figure 12. Excavator Conveyor with internal view .................................................................... 22

Figure 13. CAD model of LOADER wheel design. ................................................................... 24 Figure 14. CAD model of the base design, with electronics and battery side-support. ................ 25

Figure 15. Image of LOADER, indicating the position of the battery mounts and conveyor support

post.. ......................................................................................................................................... 26

Figure 16. CAD model of the LOADER conveyor subsystem. .................................................. 28 Figure 17. Chart for 775pro motor, showing operational levels of multiple aspects (VEX Robotics,

n.d.). ......................................................................................................................................... 29 Figure 18. Side view of LOADER in the starting, compact configuration. ................................. 29

Figure 19. CAD model of the full LOADER in its driving configuration. .................................. 30 Figure 20. CAD model of the full LOADER system in the digging position. ............................. 31

Figure 21. Diagram showing the connection of all the electronics on the robot. ......................... 33 Figure 22. Initial Structure of the Robot’s Software Environment .............................................. 35

Figure 23. Initial ROS Diagram ................................................................................................. 36 Figure 24. Example of a ROS2 Action ...................................................................................... 37

Figure 25. Image captured from Intel RealSense displaying the distance gradient in meters, with

an RGB image for comparison. ................................................................................................. 42

Figure 26 – The dynamic Bayes network that characterizes the evolution of controls, states, and

measurements (Mahroos, Hassan, & Shaaban, 2011) ................................................................. 43

Figure 27. Implementation of OpenVSLAM for obstacle detection and field mapping .............. 44 Figure 28. Example of fiducial that would be placed on collection bin ...................................... 45

Figure 29. Entity Relationship Diagram (ERD) for LOADER ................................................... 48 Figure 30. The Component table as represented in the ERD ...................................................... 49

Figure 31. The Component and Subsystem tables and their relationship .................................... 50 Figure 32. The Run and Subsystem tables and their relationship ................................................ 51

Figure 33. Individual Components and their relationships ......................................................... 52 Figure 34. Laser cut wooden prototype assembly ...................................................................... 54

xii

Figure 35. 3D printed internal insert for the prototype buckets. ................................................. 54 Figure 36. Prototype CAD Model of 0-degree bucket (left) and 30-degree bucket (right). ......... 55

Figure 37. Conveyor Excavator Prototype to calculate digging force in flat-bucket orientation

(left), and a closeup of the bucket at approximately 10 degrees (right). ...................................... 57

Figure 38. Potentially longest path for robot navigation, used to calculate robot speed. ............. 59 Figure 39. Free body diagram of torque required to drive one wheel.......................................... 61

Figure 40. Free body diagram of the top view of the chassis, use to calculate resultant friction

force. ......................................................................................................................................... 62

Figure 41. Four bar free body diagram, summed around point D ............................................... 64 Figure 42. Four bar link one free body diagram, summed around point A .................................. 65

Figure 43. Four bar link three free body diagram, summed around point D ................................ 65 Figure 44. Four bar motion study settings .................................................................................. 67

Figure 45. Four bar motion study one results ............................................................................. 67 Figure 46. Four bar motion study two results ............................................................................. 68

Figure 47. Bucket forces free body diagram, summed around point A ....................................... 69 Figure 48. Bucket forces free body diagram, summed around point B ....................................... 70

Figure 49. Allowable Forces per Insert in N (Perpendicular to Belt Surface............................... 71 Figure 50. Free body diagram of attachment point of the conveyor piston ................................. 72

Figure 51. Heat Sync Flow Chart .............................................................................................. 76 Figure 52. Example of PBS, breakdown of systems, subsystems, and parts. .............................. 83

Figure 53. Example of the material order list, showing the electronic components section. ........ 85 Figure 54. Sketch of various details regarding external and internal auger components ........... 106

Figure 55. Sketch of potential auger design ............................................................................. 107 Figure 56. Sketch of potential drill design with delivery hole at the top ................................... 108

Figure 57. Sketch of potential auger mechanism ...................................................................... 109 Figure 58. Sketch of potential auger mechanism being put in the ground, and depositing contents

............................................................................................................................................... 109 Figure 59. Four-Bar Matlab calculations ................................................................................. 111

Figure 60 The Sequence diagram for the orietation phase. ........... Error! Bookmark not defined. Figure 61 Sequence diagram for the navigational phase. .............. Error! Bookmark not defined.

Figure 62 Sequence diagram for the digging phase. ..................... Error! Bookmark not defined. Figure 63 Sequence Diagram for the return navigation phase. ..... Error! Bookmark not defined.

Figure 64. Sequence diagram for the dump phase. ....................... Error! Bookmark not defined.

xiii

Tables

Table 1. Arena dimensions for 2020 competition. ...................................................................... 11

Table 2. Robot dimensions for 2020 competition. ...................................................................... 12 Table 3. Robot Runtime for 2020 competition. .......................................................................... 12

Table 4. Distance from axel to bucket teeth in two configurations for digging conveyor testing, the

average-peak and steady forces read on the gage, and the calculated forces at the bucket teeth. . 57

Table 5. Sinkage Calculation for Robot Wheels......................................................................... 59 Table 6. Variables used to calculate resultant friction force. ...................................................... 63

Table 7. Four-Bar variable lengths (in millimeters) ................................................................... 65 Table 8. Equations of equilibirum for Four-Bar Free Body Diagram analysis ............................ 66

Table 9. Lengths from bucket free body diagrams ..................................................................... 70 Table 10. Equations of Static Equilibrium for bucket free body diagram, summed around point A

................................................................................................................................................. 71 Table 11. Equations of Static Equilibrium for bucket free body diagram, summed around point B

................................................................................................................................................. 71 Table 12.Values for Gas Springs on Conveyor .......................................................................... 72

Table 13. Power Budget for LOADER ...................................................................................... 74 Table 14. Amount of data collected per a table and over twenty runs ......................................... 78

Table 15. Risk Mitigation Table for each problem ..................................................................... 79 Table 16. The budget from the cost plan, showing all contributions. .......................................... 86

Table 17. Performance strengths of different mobile power sources (Suppes & Storvick, 2016). E,

excellent; G, good; F, fair; P, poor; I, insufficient data............................................................... 89

Table 18. Sinake Calcuations for Robot Wheels ...................................................................... 110 Table 19. Four bar static analysis force results......................................................................... 111

Table 20. Bucket static analysis force results ........................................................................... 112

1

Introduction

We live in an exciting time and place for space exploration. NASA is amid several exciting space

exploration programs including ARTEMIS and the Moon to Mars program. ARTEMIS seeks to

establish a strategic lunar presence and will land the next American astronaut on the moon by 2024

and partner commercially by 2028. The moon will then act as a proving ground for engineering

feats used to make the jump to Mars. Between modern engineering advancements, innovation, and

commercial partnerships, NASA has the potential to rapidly usher in a new, interplanetary age.

Not only is the competition a valuable experience for all involved, but it is also a way to collect

innovation for future use in NASA’s push for a sustainable lunar installment. For example, the

discovery of water just beneath the lunar surface has made it possible to imagine sustainable

research on the satellite and has shaped the rules for this year’s competition. Small concentrations

of water are present under just a few centimeters of lunar dust, so the main goal of this year’s

Lunabotics challenge is to design robots that can dig through several centimeters of sand and

retrieve the larger rocks that range in size from two to four cm beneath.

The goal of the project is to have a robot built to all the specifications of the competition, with the

capabilities to perform well at the given tasks. The engineering project the team faced to address

this goal included challenges from multiple disciplines including mechanical, electrical, and

software engineering. The interdisciplinary nature of the project necessitates high levels of sub-

team communication and coordination. Design choices were made to optimize compatibility and

transferability as the project will be passed down to future teams, and a key to incremental

improvement each iteration is a swift onboarding process. Because the rover is intended to mine

in locations like the Moon and Mars, which the team considered both the realistic constraints of

the simulated competition environment and the future constraints of those extreme environments.

2

Having provided information on the environments within which NASA robots may one day

operate on both the Moon and Mars, we will primarily use the defined specifications of the actual

operating environment of the competition. We documented the design decisions and all the

competition specifications. Finally, all the testing and results are depicted in the end.

3

Background

NASA Robotic Mining Competition

Figure 1. NASA’s Lunabotics Logo

“NASA is called to land American astronauts, including the first woman and the next man on the

Moon by 2024. We’re committed to achieving this bold goal. Through the Artemis program, we will

go to the Moon in a way we have never gone before – with innovative new partnerships,

technologies, and systems to explore more of the lunar surface than ever before. Then we will use

what we learn on the Moon to take the next giant leap – sending astronauts to Mars.”

-NASA Administrator Jim Bridenstine

The NASA Robotic Mining Competition (NASA RMC) began in 2010 and is now known as the

Lunabotics competition. The competition gathers student teams from 50 universities and tests their

robots that are designed to mine on the moon and mars. The challenge simulates the lunar surface

and requires each robot to dig, collect, and deposit as much regolith as possible within a 15-minute

time frame. Robots may operate via teleoperations, or with any blend of autonomy. Teams are

encouraged to operate autonomously and are scored higher if they do. Along with the competition,

there are awards in a variety of categories. Appendix A lists the available awards and requirements

which range from collection points to the Rookie Award for best performance from a new team.

These awards gave the team additional objectives to strive for while designing the robot for the

4

main challenge. Lunabotics has evolved over the years. This past year, an overall reduction in the

maximum dimensions and mass of the robot has forced many teams to rebuild from scratch.

Through this competition, NASA continues to challenge college students to engineer solutions for

some of the hardest problems involved in the sustainable exploration of the Moon and Mars.

Previous WPI Entries

WPI has been competing in the Lunabotics competition for years, each year improving upon the

next. This allows the team to stay competitive by improving different aspects of the robot based

on the team's skillset year to year. The rule changes this year has forced a complete mechanical

design overhaul and has forced the team to design under a much more stringent size budget.

Software In previous years, several WPI teams have based their robot design around Markhor, having forked

its’ software for their own needs on Github. This system followed a model-view-controller (MVC)

architecture. The view, or the GUI, was programmed with Java, its Swing library was used if the

robot needed manual control. The controllers, the interface between the models and the view, were

programmed in C#. Finally, the model, or the logic structured by the data in the problem, was done

in Python.

Past Strengths and Weaknesses The past WPI teams have excelled in different areas of the challenge. Markhor had an elegantly

designed dumping mechanism that had the digging mechanism completely move out of the way (

see Figure 2).

5

Figure 2. Markhor

The engineering was very elegant, but the digging mechanism was not quick or robust enough to

match the delivery system. The digger design became the efficacy chokepoint for the whole system

even though the delivery system could handle much more. Markhor also had scoops engineered to

break up gravel and collect it. But the chain system the buckets were attached to struggled to dig

to a valuable depth. Last year, the key aspect of the robot that needed to be improved upon - the

digging mechanism - was not the focus. Instead, the vision was improved. There was a small

change to the digging mechanism that did not improve the overall performance of the system.

Small mechanical errors caused many of the problems during the 2018-2019 project. Although

each team solved many issues, the digging mechanism was not improved. Learning from their

mistakes, the team will put more effort into the digging mechanism such that it might succeed

where others have failed.

6

Mars

Mars has been the target for humanity for decades. Not only is it very close to the earth, but it also

has a tolerable atmosphere and previous missions have discovered water there. The feasibility of

life on Mars is relatively high compared to other environments in space. A journey to Mars to

establish the infrastructure for long term research opportunities would require mining the water

below the surface, and this infrastructure will contribute to future establishments on the celestial

body.

Martian Atmosphere There are distinct differences between the atmospheres of Earth and Mars. The composition

breakdown is illustrated in Figure 3:

Figure 3. The five most abundant gasses in the Martian atmosphere plotted logarithmically (Dunbar &

Greicius, The Five Most Abundant Gases in the Martian Atmosphere, 2012)

The most prominent gas in the Martian atmosphere is CO2, a potent greenhouse gas. Although it

is the dominant component of the atmosphere, CO2 does not produce a greenhouse effect equal in

magnitude to that of Earth. On Earth, CO2 makes up only 0.04% of the total volume of gasses,

7

however, Earth is warmed by ~33°C by the greenhouse effect. By contrast, Mars only experiences

~5°C of warming from the greenhouse effect due in part to the lack of water vapor in Mars's

atmosphere, and because of the atmosphere’s low density. The mean atmospheric pressure on the

Martian surface is ~0.6% that of Earth's atmospheric pressure. This discrepancy is largely due to

the lack of a magnetosphere around Mars. Without the magnetosphere, solar winds “blow”

particles from the atmosphere and into space (see Figure 4).

Figure 4. The solar wind (beige streaks) rips molecules from Mars’ atmosphere. Orange lines represent high

energies of outgoing ions, blue low (Shirah, 2015)

As a result of low atmospheric density, the CO2 molecules are much less efficient at absorbing

radiation rebounding off the surface of Mars, thus the weak greenhouse effect (Planetary Sciences,

Inc, n.d.). The atmospheric pressure is also highly dependent on the Martian seasons. Mars

experiences extreme seasons due to its highly elliptical orbit, and axial tilt that is slightly greater

than that of Earth at 1.5 degrees. These two factors vary the amount of sunlight hitting certain parts

of the planet, which in turn drastically changes the temperature as there is very little temperature

moderation via the atmosphere as previously addressed. For example, during southern winter,

8

when Mars is at its apogee, temperatures can reach -125°C at the southern pole. In these winter

conditions, CO2 from the atmosphere turns from a gas to a solid and forms polar caps of dry ice.

So much CO2 de-sublimates that the atmospheric pressure drops ~25% or more and has been

measured from 8.7 Mb to 4.0 Mb (Caplinger, 1994). The trend can be seen in Figure 5.

Figure 5. A smooth curve of atmospheric pressure along with the same time frame.

Another notable feature of the Martian atmosphere is its height, which extends ~10km from the

surface of Mars, and has a total mass of ~2.5 x 1016 kg (Williams, 2018). Dust is responsible for

the red hue of the atmosphere, but the dust can be much more detrimental given more violent

weather patterns. Dust storms are common in the southern hemisphere during the spring and

summer, often covering wide swaths of land and lasting for several days. However, much larger

storms have been observed. These larger dust storms span the planet and can last for months. The

first observed global dust storm happened in 1971, seen by Mariner 9. Since scientists have

observed similar storms in 1977 (twice), 1982, 1994, 2001, 2007, and 2018. The storm in 2018

was responsible for decommissioning the Opportunity rover. These storms present an

unpredictable, dangerous factor in all Mars operations. Furthermore, they may be responsible for

molecular water loss over billions of years (Shekhtman, 2019).

9

Operational Challenges In addition to the significant atmospheric and temperature differences, operating on Mars presents

other challenges unlike any that can be experienced on Earth. Mars is, at any given time, between

54.6 million and 401 million kilometers from Earth, although humans have never observed Mars

at its theoretical minimum separation. This separation makes any direct teleoperation of a Martian

robot impossible because of the signal delay ranging between four and twenty-four minutes,

averaging around thirteen minutes. Operationally, that means that crews on Earth can, at best, react

in 26 minutes. Therefore, robotic operations must be autonomous and must avoid relying on

teleoperation for critical systems (Ormston, 2012).

10

2020 RMC: Lunabotics

As mentioned, dimensions for the robot were reduced in every direction to emulate an actual

payload that would be deployed on the Moon or Mars. The robot is designed for off-world

plausibility, all the physical processes, gases, fluids, and consumables must be capable of working

in extreme conditions beyond the Earth's atmosphere. Other design considerations include safety,

communication, and navigation.

Navigational aids of the system may not be higher than a quarter of a meter above the sieve frame,

cannot be permanently attached, or caused alterations. A forty-millimeter diameter, visible, red

“kill switch” is also required, and is just one example of the safety considerations taken.

The robot must be able to mine through approximately thirty centimeters of a lunar dust stimulant

called BP-1, which will expose a bed of approximately fifteen centimeters of an icy regolith

simulant bellow - which is gravel, as seen in Figure 6.

Figure 6. Icy Regolith simulant (gravel), at various sizes (Heiney & Johanboeke, RMC Icy-Regolith Simulant,

2018)

11

Current Rules and Restrictions

For a robot to qualify and be awarded points in this year’s competition, it must meet the dimension

specifications located in Table 2. If the robot exceeds them it may still compete, as long as all of

the other rules are met, such as safety, communication, and so forth. A team must complete a

systems engineer plan and paper, and conduct a public outreach program with an accompanying

report. Not completing these other requirements bars the team from this year’s competition. Along

with the changes to the robot’s dimensions, the competition runtime (see Table 3) was changed

from a ten-minute setup and ten minute mining time. The arena dimensions in Table 1 remain

unchanged since the previous year.

Arena Dimensions

Length (meters) ~5.4

Width (meters) ~3.6

BP-1, regolith simulant depth (cm) ~30.0

Gravel, icy-regolith simulant depth (cm) ~15.0

Table 1. Arena dimensions for 2020 competition.

12

Robot Dimensions

Maximum Length (meters) 1.00

Maximum Width (meters) 0.50

Maximum Height (meters) 0.5

Mass (kilograms) 60.00

Table 2. Robot dimensions for 2020 competition.

Robot Runtime

Robot Arena Set-Up (minutes) 5

Robot Mining Time (minutes) 15

Robot Extraction (minutes) 5

Table 3. Robot Runtime for 2020 competition.

Robot Deliverables

The deliverables for what was completed on the robot will address three main things; meeting the

new parameters set by the challenge, a new digging and driving design, and collecting more than

one kilogram of regolith in a single run. Along with new designs, there will be analysis for the

drivetrain including sinkage calculations, necessary angle for the excavator system, the placement

and speed of the deposit conveyor, and the torque required to reliably collect regolith simulant.

ROS will control the robot using a system of abstracted nodes, and packages. It will manage the

communication within the robot and handle any error conditions that may arise. Furthermore, it

13

will allow for easy readability and modification for future groups. A circuit diagram will be created

to lay out the hardware components and show the necessary power draw. Also, heat sink

calculations are available for the electronic components inside a dust-free encasement to ensure

they won't overheat and malfunction.

Additionally, some possible usages of regolith as a renewable energy source going to detail. In

preparation for the continuation of this project, the documents collected and created during this

year will be organized to make sure there are a few difficulties as possible. This means having all

of (but not limited to) the following documents available and organized: SolidWorks models,

analysis documentation, forms ordering and tracking parts, and a list of available parts/material

and their locations. The team also hopes to provide insight into what a project of this size will take

to complete, such as timesheets, and skill matrixes.

System Requirements Review

The team worked on and presented a system requirement review. This review ensured the team

had an exhaustive list of goals moving forward. This review was divided into NASA provided

constraints, functional requirements, non-functional requirements, and software requirements.

The robot must meet given specifications of the competition guidelines provided by NASA

including weight, size, bandwidth, power, and dust management.

Functional requirements are as follows:

• The robot shall complete two full cycles of operations within 15 minutes.

• The robot should be able to dig continuously.

• The digging wheel shall collect 1 kg of icy-regolith in less than 1 minute.

• The digging wheel shall operate in clockwise and counterclockwise directions.

• The containment shall be able to hold a minimum of 1 kg of regolith.

14

• The delivery conveyor shall deploy passively.

• The delivery conveyor shall discard regolith from icy regolith.

• The drivetrain shall not stall under a 61 kg load.

• The digging wheel shall be durable enough to accomplish ten 15-minute collects.

Non-functional requirements of the robot include the following:

• Base

• The base shall not have a mass greater than 45 kg.

• The drivetrain shall have at least 2 motors.

• The power distribution shall contain a clearly visible kill switch.

• All electronics shall be environmentally sealed against conductive dust.

• The containment shall sense when 1 kg is present.

• The delivery shall minimize dust production while operating.

• Digging Wheel

• The wheel shall not move the CG outside the bounds of the drive chassis.

15

Software requirements of the robot include:

• The robot shall not utilize a compass or GPS for path calculations.

• The robot shall be able to run using teleoperation.

• The robot should be able to run fully autonomously.

• The robot should be able to continuously monitor all systems.

16

Design

Mechanical

The NASA RMC: Lunabotics 2020 competition had revisions to the rules and requirements which

more closely align with, and support the parameters of, the Artemis lunar exploration program

(previously detailed). There were substantial changes to the parameters of the robot including both

the weight and size having been reduced, requiring the team to design a new model for the robot.

The previous robot had a much larger digging system than what can be implemented under the

new rules. To fulfill the new requirements of the competition the team decided to investigate

different and smaller methods to both maneuver and collect regolith through prototyping. The

results indicated that a completely new robot design, build, and software base was necessary, thus

warranted a new testing phase.

On top of designing a new robot, the team also restored the previous years' robot to operating

conditions for a groundbreaking event and put additional focus on other competition requirements

such as outreach, documentation, and team organization. With all of this in mind, a schedule of

due dates was generated and followed throughout the design process of the robot. The first stage

included in-depth research of new digging mechanisms, and other critical features; the

programming language, components that could be reused from the previous years' robot, and new

components that would need to be used. Following this research were the prototyping and CAD

design phases, which allowed for analysis and testing. Parallele with these steps included outreach,

program design, and manufacturing consideration.

17

Excavation Designs A major focus of the new robot design was developing an efficient and competitive digger. Since

a new digging design was necessary for the team to face up to more rigorous competition

requirements, multiple design iterations were explored before the final design was chosen.

Auger The first digging mechanism design considered by the team was an auger, and when compared to

the previous conveyor-style digging mechanism, a drill-type digging mechanism could improve

the excavating efficiency of the robot while conforming to new constraints (see Figure 7). Drill

digging has been used for boring throughout the 18th century. Typically consisting of a screw-

type attachment to a drilling motor, the digger is encased in a cylindrical body to contain dug

material. In the case of regolith mining, it should include filtration layers to sort material by size.

Below are sketches of the initial concept for the auger-type drill piece.

The current desire for the depth of the digging mechanism is forty centimeters deep which is

comprised of thirty centimeters regolith and ten centimeters of icy regolith. This would strike a

balance between a favorable regolith to sand ratio while limiting the depth the drill must reach.

18

Figure 7. Sketch of proposed digging mechanism, showing the internal chamber (top right), and the outer

drill shell opening to deposit material into the collection bin (bottom left).

The main issue with this design, however, is manufacturing something so unique. It did not seem

feasible due to the vast amount of expensive custom machining required to build the auger. It was

decided this was beyond the team’s capability, cost range, and subsystem weight limit. Finally, the

design would also complicate other subsystems to accommodate the unique design. Ultimately, it

was decided to abandon this design for the 2020 competition.

19

Bucket Wheel After ruling out the auger design, an excavator wheel design was investigated. This concept

includes an angled digging wheel which would have teethed buckets, spaced about the center to

collect material (see Figure 8 and Figure 9). Compared to the auger, this design seemed more

feasible in terms of manufacturing.

Figure 8. Excavator Wheel Assembly

Figure 9. Excavator Wheel Assembly expanded

20

One issue the team was able to solve with the bucket wheel excavator was how to guide the

material through and out of the wheel onto the conveyor while moving against gravity. To do this,

the team optimized the design of a “bucket insert” which could be 3D printed for each bucket

compartment inside the wheel as shown in Figure 10. The shape of this insert is curved to allow

material to pick up velocity, and it ends at a 30-degree angle to be sure the material does not slow

at the exit. It allows the material to gain speed on the curved edge, and by the time the material is

at the top, it exits the wheel horizontally.

Figure 10. 3D-Printed guide for excavator wheel

Although the team moved forward with prototyping and fully modeling the excavator wheel design

in CAD, the design was not chosen. Most notably, the design would not collect enough material.

This is due to its size and the power limitations of the motors. If a larger motor was chosen, it

would not have fit on the chassis. Another reason was the difficulty in maintaining a 30-degree

angle within such a small bot. The geometry required to accommodate this angle consumed an

excessive amount of space for the starting size restrictions. A four-bar mechanism was chosen to

position the digging mechanism. The team also had difficulty positioning the four-bar on the robot

due to interference with the containment conveyor, which could not be fixed without decreasing

21

the size of the digger. Overall, this could be a useful design if developed further, but the team ruled

this to be out of the scope for this year’s project.

Conveyor LOADER was ultimately designed with a motorized digging conveyor to excavate material. This

digger consists of the conveyor system, its motor, ten excavating buckets, and secure fasteners.

The belt system that was chosen is a sturdy polyamide profiled belt and pulley with customizable

size. The decision to go with a belt instead of a chain was based on the amount of surface contact

provided by the driven pulley to the belt which addresses issues with chain systems such as slipping

or falling off sprockets due to debris buildup. An issue in the past with other conveyor excavators

was the radius of the pulleys which is difficult for the buckets to maneuver about. Due to this, the

pulley chosen for LOADER was maximized. The conveyor is powered by a Falcon 500 motor.

Due to the high power this motor provides and customizable gear stages, it can be geared based on

required torque determined during testing. The bucket design was based on the tested Ibex buckets

which were already built and available for use. Some features of this design that will be reused

include the durable machined bucket teeth and the general shape of the sheet metal. This can be

seen in the comparison in Figure 11.

Figure 11. CAD model comparison of current LOADER bucket design (left) and the previous year’s robot

bucket design (right).

22

The fasteners on the buckets include a hinge and bump system to aid in revolving around corners,

as well as strong screws designed for the custom belt which can withstand 170N of perpendicular

force. Since the bucket is flat, when it revolves about the pulleys on the conveyor one side has to

“lift” up off of the bucket. The bump provides support at the back of the bucket, and the hinge

includes a spring preventing it from swinging forwards, as shown in Figure 12.

Figure 12. Excavator Conveyor with internal view

Wheels vs. Treads

The previous robot used tank treads to traverse the field. Treads have more contact area with the

ground than the typical wheel making them appropriate for a terrain composed of the lunar

simulant by distributing the weight of the robot over a larger area. Because of this, treads prevent

heavier robots from sinking into the fine simulant which can create drag and even immobilize the

robot. Treads are also able to manage obstacles without the use of a suspension. Unfortunately,

treads are not as effective at maneuvering when compared to conventional wheels, and this was

23

one of the numerous reasons the team considered when deciding to go with wheels. Along with

greater maneuverability, wheels are lighter than treads, which has become a key factor considering

new mass constraints. Using wheels, therefore, allows weight to be allocated into other sub-

systems such as the digging mechanism. The second advantage of wheels is space. Given the size

of the drive chassis, treads would use up over half of the width of the chassis. Finally, wheels

provide speed, lightweight (compared to treads), and overall maneuverability. The team also

believes that wheels will be easier and faster to produce.

To improve maneuverability, grousers are added to each wheel, as this increases forward motion

performance. Researching grousers as rover wheels, it was found that a fifteen-degree spacing,

ten-millimeter grouser height, and 1.5-millimeter thickness is was preferable for a 200 to 400-

millimeter diameter wheel (Liu, Gao, & Deng, 2008). The diameter of the robot's wheels are 254

millimeters, this indicates that twenty-four grousers should be added to the wheel. The study that

was done used completely solid wheels, and since the wheel is mostly empty and will be

lightweight, it was decided that twelve grousers will be attached. An angle of 30 degrees between

each grouser will help to keep multiple grousers in contact with the soil at once (see Figure 13).

Changing from treads to wheels requires sinkage calculations, torque analysis, and stress analysis

to determine how the wheel will perform in the simulated environment.

24

Figure 13. CAD model of LOADER wheel design.

Linkage

To actuate the digging conveyor, a four-bar linkage was chosen based on its versatility. It was

determined the four-bar links would be made from a strong material - aluminum tubing - to bear

loads in both operating positions and shear stresses on the driving link. It was determined early on

that a worm gear motor would be ideal for providing the desired anti-back drive condition while

in the static digging position due to its high gear ratio. To connect the four-bar links to the digger,

sturdy bearings and torque transfer couplings were chosen to ensure the best connection at the

links and the least amount of friction while rotating about the connecting points.

Base

Due to the reduction in maximum size discussed in Section 3.1, the entire robot needed to be

redesigned. Few components of the old robot could be reused, as they were all specific to the

previous robot and its goals. The team chose a lightweight, open frame design for the base to

25

accommodate the current design and allow for future modifications. The U-shaped base was

designed to maximize subsystem space and an operational range of motion (see Figure 14). The

main structure consists of two rectangular tubes that are each four hundred millimeters long with

a 50.8-millimeter by 25.4-millimeter cross-section. These tubes also serve as the housing for a

timing belt-and-sprocket drivetrain system. Enclosing those components inside ensured minimal

dust would come in contact with the belt. To further reduce dust build-up, 3D printed caps will go

on both ends of tubes.

Figure 14. CAD model of the base design, with electronics and battery side-support.

The front of the base has the wheels attached with Vex VersaBlock (Vex Robotics, n.d.), which

allows adjustment to the toothed belts. Room was allocated for the fasteners for other subsystems

26

and interactions with the pulley system have been avoided by using short screws that do not extend

past the threaded holes.

In addition to providing support, fastened brackets at the rear of the base house the drivetrain

motors and the electronics box. Since these motors are positioned under the containment system,

they also help to counterbalance the digging mechanism. On each exterior side of the frame is a

mount that holds one of the two batteries, a diagram of this is shown below in Figure 15. These

are placed between the wheels to give the motors and electronics box enough room to stay cool,

and to give the robot an even weight distribution so the robot is not front or back heavy. A post is

attached near the back of the base that gives the extra support to the conveyor once it is in its final,

extended configuration. This reduces the constant force applied to the conveyor pistons and adds

extra stabilization.

Figure 15. Image of LOADER, indicating the position of the battery mounts and conveyor guide rail.

27

Passive Lift Containment To meet the requirement of delivering material collected to a 0.6-meter-high collection bin, the

team designed a passive-lift conveyor. When designing the entire robot it was determined that the

containment system does not have to move after it reaches its final, extended position. Thus a

passive lift is the most advantageous, as it will consequently reduce the weight and power draw.

The passive lift mechanism utilizes a sealed, damped spring which is much lighter than the motor

alternative. Since there is no reason for this containment to return to its original position, this is

the best place in the design to eliminate electronics and power draw. The containment system will

only need to fit within the size constraints at the beginning of the competition because once it is

deployed, the size constraints (from the competition rules) no longer apply. The full design (as

shown in Figure 16) is lightweight, with polycarbonate sides and front of the container, and a

lightweight belt from a treadmill that makes up the conveyor.

28

Figure 16. CAD model of the LOADER conveyor subsystem.

The front piece has cutouts for the teeth of the digging mechanism to come through, as well as

help sift through the regolith and only allow icy regolith to be collected. The slides, located at the

bottom of the subsystem, seen in Figure 16, indicate how the team has made a passive sealed,

damped spring work without the sealed, damped spring: the slides move the conveyor with the

springs with relatively no friction. The full movement of the containment conveyor is moving back

and up. A Vex 775pro motor will power the conveyor, and move the material from the containment

area to the delivery area. It was chosen because the motor has been used in the previous robots

meaning it was already in the inventory. The 775pro has enough power to move the icy regolith

from the robot up to the 0.6 meters drop off point using the grousers on the belt. When working

with the motor it will not pass the first twenty percent on the motor graph shown in Figure 17.

29

Figure 17. Chart for 775pro motor, showing operational levels of multiple aspects (VEX Robotics, n.d.).

Final CAD Over numerous iterations, a final Solidworks model was created. Three different configurations

were modeled, with the figure below (see Figure 18) being the starting configuration.

Figure 18. Side view of LOADER in the starting, compact configuration.

30

This configuration is only used at the beginning of the match to stay with starting restrictions of

the competition. After the competition has started, LOADER switches to the driving configuration

(see Figure 19).

Figure 19. CAD model of the full LOADER in its driving configuration.

The driving configuration is used throughout the match to get to and from the dig site and dumping

location. As shown in the figure, the digger is slightly extended and the drop-off conveyor is

positioned in a collection manor. Finally, in Figure 20, an isometric view of the terminal digging

configuration is shown. When in its terminal point, the digger can reach to deepest elements of the

field. This allowed for the most optimal collection of the icy regolith.

31

Figure 20. CAD model of the full LOADER system in the digging position.

Mass Budget

Per the requirements of the competition, a mass budget is required to track the weight of the parts

and the weight of the entire robot. To complete this, material properties are added to each part of

the CAD model or taken from specifications – such as with motors for example. As the materials

are updated the weight is added to the Product Breakdown System (PBS), which is explained in

more depth in Section 6.2. In short, the PBS is a master list of parts for the entire system, which

includes part counts and weights. This keeps track of the overall weight. Additionally, after the

estimated weight of the robot is determined, and the robot is completed, an actual total must be

determined to ensure the system meets the competition requirements.

The three main considerations when deciding on the weight of the robot were: 1) maximum load,

2) competition points, and 3) future changes to the system. The maximum weight the robot can be

is sixty kilograms, and as the robot only needs to deposit one kilogram, the robot’s operational

32

weight is calculated using sixty-one kilograms. The second consideration is for future

improvements. The total weight of the robot shall be forty kilograms, as opposed to the maximum

because a robot that weighs sixty kilograms does not score any weight-based points and leaves no

room for future additions. For every kilogram the robot weighs, the team is deducted 8.00 points;

the less the robot weighs the fewer points the team is deducted, with a maximum deduction of

480.00 points. A forty-kilogram robot costs the team 320.00 points from the overall score.

Future changes to the system were taken into consideration as well. Giving the next team a mass

allowance to make changes to the design is crucial for successfully continuing this project.

Allowing for up to twenty kilograms of mass to be added to the system creates a reasonable buffer

for improvements to any subsystem, electronics, power, or digging/depositing.

Electronics

The Base power distribution system consists of two twelve volts, twenty-two amp-hour, Sealed

Lead Acid batteries in series. This capacity has an 11% margin over the required 467 watt-hours

for the fifteen-minute regolith collection. The electronics of LOADER are distributed into different

voltage lines and data transfer lines, as shown in Figure 21. The Jetson, Rasberry Pi 4 CPU, and

HERO Boards will be encased in an aluminum enclosure with a removable lid for protection

against the regolith dust. The enclosure will also perform as an aluminum heat sink for the

electronics. The energy consumed by the robot will be recorded with a “Commercial Off-The-

Shelf” (COTS) electronic data logger and be visible to the judges after the competition. Per the

competition rules, and an emergency stop switch is required.

33

Figure 21. Diagram showing the connection of all the electronics on the robot.

The Robot contains five motors: two 24V motors and three 12V motors. The two 24V motors

control the drivetrain. Each one of the three 12V motors controls one of the following subsystems:

the bucket conveyor, the four-bar linkage, and the offload conveyor. The drivetrain motors are

both controlled using an ODrive motor controller that allows fine-tuning of PID, easy

compatibility with ROS, and limits the current provided to the motor. The bucket conveyor motor

is controlled through a CAN bus, beginning at a HERO Board and

ending at the voltage regulator module. Two Talon controllers regulate the voltage to the four-bar

and conveyor motors and send data from the encoder back to the HERO Board.

The robot also contains four sensors: a potentiometer, an IMU, and two IR sensors. The

potentiometer is connected to one link of the four-bar mechanism. It can read the position of the

four-bar at any given time. The IMU is used to determine if the robot's tilt angle is too great in

34

situations such as driving over a rock or entering a crater that is too steep. Finally, the two IR

sensors are used to check how much material is in the collection bin. If neither sensor is providing

a signal for a given amount of time, it is assumed that the bucket is empty. If the upper sensor

provides a signal the bucket is full of icy regolith.

Software

This year, the Robot Operating System (ROS2) was used to control the robot. With ROS2, the use

of an action-based communication environment was utilized to send and receive data from the

sensors on the robot. There are several components of the software structure that operate outside

of the ROS network. Finally, the software has a sequence-based design and will be using a database

to track the robot’s states and save states across hard system-restarts. This functionality enables

the robot to pick up a given sequence of actions from any point along the process, even after a

complete shutdown.

ROS2 The decision to use ROS was supported by several factors. First, ROS is a standard in robotics.

This means there is widespread support for many of its capabilities and will therefore be much

easier to work with. Several teams in the past have worked with ROS, and there was more team

familiarity with the environment. It will also be easier for future teams to onboard, assuming it is

more likely that they have worked with ROS rather than any other framework.

ROS2 has support for a variety of libraries that are geared towards completing common robotics

tasks, navigation for example. These libraries can be leveraged to accomplish the complex tasks

that the competition requires.

ROS2 is not optimal for real-time operations. This is the biggest drawback of the framework.

However, the competition does not require a real-time response for success. Measures were also

35

taken to reduce the bandwidth usage across the ROS network at any given time during operation.

The high-level ROS2 network design is shown in Figure 22.

Figure 22. Initial Structure of the Robot’s Software Environment

The decision to implement ROS2 has driven many of the following design choices. The initial

ROS structure was much more complex, including many more components of the robot. The initial

diagram is shown in Figure 23.

36

Figure 23. Initial ROS Diagram

To maintain efficient use of bandwidth the team encapsulated much of the complexity seen above.

First, the visual subsystem was removed from the ROS network, thus encapsulating all the raw

visual data communications into a node that will only communicate processed data across the

network. Furthermore, all the services and topics have been replaced by actions. Actions will be

discussed in the following section. Similarly, there is no Raspberry Pi represented in the initial

graph. This change will also be discussed in later sections.

37

Actions Actions are a compound communication method implemented in ROS and improved upon in

ROS2. Actions initialize a command, receive status updates while the command is executing, and

then receives a completion message. This communication protocol replaces both the ROS service

and the ROS topic. The topic operates on a publish-subscribe method, while services operate on a

request-response method. Topics are used for continuous data transmission. The robot requires

constant transmission on the motor controllers and the IMU sensor. Services are needed for non-

continuous data transmission. The robot requires non-continuous data transmission for the real

sense camera, potentiometer, and database system. Actions can fulfill both needs. An example of

ROS2 action communication is detailed in Figure 24.

Figure 24. Example of a ROS2 Action

The first message sent is a goal. This goal is one node asking for another to perform the task and

return when the goal is reached. Once the goal is accepted, the action server waits for feedback.

Feedback can return continuously until the goal has been accomplished. Once the goal is

completed, or an error case arises, the receiving node will return a result to the action server. The

goal and result take the place of ROS services, and the feedback takes the place of ROS topics.

38

The types of data accepted across each different action can be configured to the specific needs of

that communication channel.

ROS1 vs ROS2 ROS1 has been the standard for a long time. Very recently, ROS2 has become prominent. ROS,

being an open-source project, thrives because of its community, and the community has not had

as long to generate as useful, and robust packages for ROS2 as it has for ROS1. However, with

the ROS2 package, a ROS Bridge was introduced which allowed for cross-communication

between the two releases. The bridge also made it possible to implement any of the packages that

might be available for version one and not version two. This is the biggest drawback for ROS2,

user support, and package availability. The ROS Bridge allays this concern. The team decided to

switch to ROS2 for two main reasons. First, ROS2 can be run on windows, whereas ROS1 must

be hosted on a Debian based machine. Although this is not a design consideration, as Ubuntu is

being used for the operating system on the PI, it is an ease of use factor that was deemed to be

important as well. Secondly, ROS2 had a much better implementation of ROS actions. Although

ROS1 does have actions, they function as more of an afterthought in all of the documentation, and

in the implementation across many open source packages. Actions are a central method of

communication in ROS2.

Raspberry Pi 4 At the beginning of this project, the main processor on the robot was the NVIDIA Jetson Nano.

The Jetson is optimized for image processing and has a dedicated GPU, however, aspects of the

Jetson prevented the computer from being fully utilized. When it became clear that the Jetson was

not capable of handling image processing as well as central communication, the team looked for a

replacement. During the formation of this solution, it was decided that the Jetson would still be

39

used to process the data coming from the cameras. To decentralize the ROS network, optimize the

connections to the rest of the sensors, and encapsulate the area of highest data traffic, the team

decided the Raspberry Pi 4 was a better main processor.

The Raspberry Pi 4 was a clear choice as it solved several issues. ROS is much easier to implement

on the Pi, and the Pi has more general-purpose input/output (GPIO) pins. Although the processing

specifications of the Jetson and the Pi are very similar, the Pi was more than capable of handling

the ROS2 network without the image processing load. Secondarily, when the Jetson was being

used as the main processor, many of the sensors were going to be connected over USB. Since the

Pi has 40 GPIO pins, the team no longer must rely on USB. This is beneficial because each USB

is assigned a different serial port every time the board is powered on.

Teleoperations vs Autonomy The Lunabotics competition offers three different ways to complete a trail: Teleoperation, Partial

Autonomy, and Full Autonomy. Teams have the opportunity to earn five-hundred more points

competing with full autonomy instead of teleoperation. Not only does this provide motivation for

a fully autonomous robot, but it is also reflective of real-world applications when communicating

with rovers on other planets. Due to the distances between Earth and other planets, the signal time

for the robot to receive commands from Earth is so delayed that the robot could not be properly

operated in real-time. Using autonomy will allow the robot to control itself and make decisions

that could not be done in the timeframe of teleoperation, therefore operating under more realistic

conditions. This, however, does not negate the need for a teleoperation system. In the case of

autonomy failure, teleoperation would have to be used. Also, teleoperation provides it’s usefulness

when testing mechanical subsystems before full deployment.

40

Sequence Methodologies The first step for designing a sequence-based software structure is brainstorming events. Then the

events are rated based on how critical they are to completion of the overall task. A critical aspect

of event generation is cross-team communication which is equivalent to requirement gathering for

a typical software deliverable. The Software Sequence Model contains all the event cases that the

team initially tried to address before extensive testing took place (Bimonte, et al., Software

Sequence Model, 2020). They aided in the creation of the sequence diagrams that outline the flow

of events, how they will be handled, and in what order they must execute (see 0). The two of those

documents make up the robot’s high-level design.

Vision and Navigation According to the rules for the Lunabotics Competition, the robot must travel to the digging site

while avoiding different obstacles on the field. This requires the use of multiple different methods

of tracking and image recognition techniques to be able to track obstacles. For this, NVIDIA’s

Jetson Nano will be used, along with OpenCV and OpenVSLAM libraries to map the environment.

To process the depth images from the two RealSense cameras, a program will identify the pixels

of the image that represented a boundary. The program would begin by opening a pipeline to allow

the camera to record data to the Jetson Nano. Once this pipeline is open, the camera can begin

imaging. After waiting between five and ten frames to initialize the image, the camera can capture

the image. Using a Depth Sensor field and distance gradient image, the image processing program

captures the total width and height of the image in pixels. The program will proceed to iterate

through each pixel, placing the distance reading into a multidimensional array and CSV file. In

this step, the processing program would compare the pixel to surrounding pixels, looking for a

large difference between the surrounding pixels. If a large distance was detected, the closer pixel

41

would be flagged as an obstacle and put into the CSV accordingly. In theory, this would mark the

outline for all obstacles, simplifying the SLAM pathfinding algorithm. Upon completion of the

data transfer into the CSV file, the pipeline will close, turning off data collection from the camera.

To end the program, the Jetson Nano sends the collected CSV file via ROS to the Raspberry Pi 4,

where the data is pushed into LOADER’s sensor database and to the SLAM pathfinding algorithm.

The image processing program can be called as rapidly as necessary to collect sufficient data for

SLAM pathfinding.

NVIDIA Jetson The NVIDIA Jetson Nano is a micro-computer commonly used for image processing due to its

onboard GPU compared to other micro-computers, such as the Raspberry Pi 4, that do not possess

one. This leads to a noticeable speed reduction in the processing of images, which is a critical

feature necessary for autonomous navigation since a delay in image processing could result in

obstacle collision or complete system failure. The task for the Jetson is to produce a map given the

images from the two cameras to be used for pathfinding.

Intel RealSense To view the field, two Intel RealSense D435i Depth cameras will be utilized, with one camera in

the front and one in the back of the robot. This system takes images from three different kinds of

cameras: an RGB, infrared, and depth. The RGB image displays what would be perceived by the

human eye allowing for the robot to be teleoperated while the depth camera allows for the

calculation of the distance to a point on the field. The depth aspect of this camera will be used for

localization and mapping algorithms that will determine the pathing of the robot. This is achieved

in part by using a custom library from Intel, called LibRealsense, to gather the depth information

from each of the cameras. The data is then processed into a user interface that displays distances

42

in meters via the color spectrum. Objects closer to the camera are displayed as blue while farther

objects are displayed as red, as shown in Figure 25.

Figure 25. Image captured from Intel RealSense displaying the distance gradient in meters, with an RGB

image for comparison.

Simultaneous Location and Mapping Simultaneous Location and Mapping (SLAM) keeps track of both where the robot is and the

environment around the robot. The input to the algorithm is a sequence of states. At each state, the

robot knows the commands it was given to get to the current state, and the observations it has while

in that state. The goal of the output is to map the environment and accurately know the path the

robot has taken. Once the robot reaches the next state, the previous outputs are used to approximate

the next set of goals at this new state. In practice, however, there is the possibility for sensor error,

which is solved using a probability function (see Equation 1), which is explained in detail in the

next paragraph.

𝑝(𝑥𝑡|𝑥0:𝑡−1, 𝑧1:𝑡−1, 𝑢1:𝑡) = 𝑝(𝑥𝑡|𝑥𝑡−1, 𝑢𝑡)

Equation 1. The probabilistic law characterizing the evolution state (Mahroos, Hassan, & Shaaban, 2011)

43

Figure 26. The dynamic Bayes network that characterizes the evolution of controls, states, and measurements

(Mahroos, Hassan, & Shaaban, 2011)

The state at time t is dependent on the state at time t – 1 and command ut. The measurement at zt

depends on the state at time t (Mahroos, Hassan, & Shaaban, 2011). A visual representation of this

can be found in Figure 26. From this, it follows that for each next state x, the probability

distribution grows, the uncertainty amplifies. At the next state, the robot can observe an obstacle

that it has previously observed to reduce the uncertainty of the location of the obstacle. Since

position xt was dependent on position xt-1 and the observation at that position depended on the

distribution of the obstacle, the algorithm can refine the probability distributions of all the variables

that depended on the old distribution for the location of the obstacle. When the SLAM algorithm

has generated a full map, simple navigation could then be used with the map. This leads to greater

movement speed due to all obstacles and locations being mapped.

OpenVSLAM and OpenCV To achieve the goals of SLAM pathfinding, the team implemented the library OpenVSLAM. This

library provides the ability to use different types of cameras and models to implement a SLAM

algorithm, allowing the algorithm to utilize all camera modules on the RealSense cameras as

needed. OpenVSLAM also allows maps to be easily stored and loaded to the Raspberry Pi. This

44

simplicity makes the process of localizing new images simple, as previously stored maps are

continuously updated with the newer images as seen in Figure 27. With the simplicity, benefits,

implementation, and testing of OpenVSLAM, the library proved to be integral to pathfinding and

field mapping.

Figure 27. Implementation of OpenVSLAM for obstacle detection and field mapping

Along with the OpenVSLAM library, the OpenCV library played an important role in field

mapping. The OpenCV library allowed objects to be located using fiducial images. A fiducial is

an icon that, when viewed by a camera, can give alignment data to the robot. The fiducials each

have identifying marks that the library can track (see Error! Reference source not found.). Since

each fiducial is unique, the OpenCV library can identify each fiducial used, and store that

information for future use. This library can also determine orientation based on the robot's location.

Using the dedicated GPU on the Jetson, the robot can use the image of a fiducial to determine its

orientation on the field. Combining the orientation features given by the fiducials with the depth

processing of the RealSense cameras and map of the field from OpenVSLAM, the robot can

determine its exact position relative to the fiducial. This process makes alignment with the

collection bin significantly more reliable, to ensure LOADER can deposit the collected material.

45

For LOADER to align with the collector bin it will use the rear RealSense camera’s RGB imaging,

to locate a fiducial that will be placed on the bin.

Figure 28. Example of fiducial that would be placed on the collection bin.

Communication With ROS being the method of communication between each subsystem, it was necessary to

provide hardware and electronic methods to send commands from the Raspberry Pi. This involved

multiple different computer systems and sensors to collect and transmit data. ODrive motor

controllers allow for the communication to the drive motors. A HERO Development Board from

Cross The Road Electronics provided a communication channel to the digging and delivery

conveyor, utilizing CAN communication to send precise data. Lastly, Ethernet connection and

IMU data provided sensor support and communication to the WiFi bridge to ensure sufficient data

transmission and collection.

HERO Development Board To control all non-drive motors on LOADER, the team opted to use a HERO Development Board.

This board, programmed in C#, allowed for the use of already-owned speed controllers, Talon

SRXs. These speed controllers, generally used in the FIRST Robotics Competition, allow for

46

precision control of brushed motors. To complement these, Falcon 500 motors from VexPro were

chosen, which are brushless motors that have a built-in speed controller.

Serial communication will be used to transmit data using the HERO development boards. With

unused GPIO pins being unused on the Raspberry Pi, along with the simplicity of data transfer,

serial communication seemed to be the most beneficial. This led to testing two different methods

of serial communication: UART (Universal Asynchronous Receiver-Transmitter) and I2C (Inter-

Integrated Circuit). Both UART and I2C are commonly used in master-slave software

environments, like the relationships between ROS nodes, and there is documentation for this

method of serial transmission over ROS. Using the ROS library, rosserial, the data from the

Raspberry Pi main node can be transmitted to the HERO boards and vice versa. The HERO boards

will then be able to send commands to the attached motors using CAN. Controller Area Network,

or CAN for short, is a protocol that has been widely used in the FIRST Robotics Competition over

the past few years and by the industry for longer. Compared to the Pulse Width Modulation (PWM)

protocol, CAN allows for the sending and receiving of messages to and from each component on

LOADER, whereas PWM can only send integer values (0 to 255 generally). This was an important

feature due to the Talon SRXs having built-in encoder ports that the team wanted to utilize. Also,

CAN could be used to send an operating voltage or amperage for each motor instead of a speed

percentage to run at.

IMU An inertial measurement unit (IMU) allows the Raspberry Pi to collect orientation data for the

robot. Through the use of an IMU, LOADER can determine its initial orientation on the field, as

well as the direction of motion and other forces applied to the robot. There are IMUs in both

RealSense cameras which will not be turned off with other functions of the camera per rules of the

47

competition. The main IMU for the robot will be located at the center of mass. Similar to the

HERO Boards, the IMU communicates with the Raspberry Pi through serial communications,

specifically I2C. The Raspberry Pi powers the IMU and communicates via the second and third

GPIO pins. Unfortunately, due to the COVID-19 pandemic, the IMU sensor was not fully

implemented nor tested.

Ethernet An ethernet communication system was chosen to tie each component together and connect to the

WiFi bridge. The team chose the ethernet standard over other standards, like WiFi or Bluetooth,

to diminish the possibility of signal interference, and to avoid increased data transfer during the

competition. In addition to avoiding signal interference, theoretical transfer speeds are greatly

superior to both WiFi and Bluetooth, due to the nature of Ethernet. Lastly, in the team's limited

testing, the ROS system was able to connect with greater ease to each of the components compared

to the wireless counterparts.

Database State monitoring is an important part of any well thought out robot design. The team decided to

implement a MySQL Database that keeps track of the various information on the robot broken

down by individual trials, subsystems, and components. When designing a database, the creation

of an Entity Relationship Diagram (ERD) is a key step. It allows for the thoughtful planning of

each table and their relations to each other. The ERD for LOADER, as shown in Figure 29,

represents how every component of the robot relates to each other.

48

Figure 29. Entity Relationship Diagram (ERD) for LOADER

49

Component Relationships One of the most important aspects of the above ERD is the Component table. The Component

table holds all the various components that exist on the robot that can be tracked. This can range

from the batteries and motors to the cameras and sensors. Each component is given a unique ID, a

name, and a device type to go along with it. Figure 28 not only depicts this but also shows how

motors and sensors pair to each other.

Figure 30. The Component table as represented in the ERD

The “Pairs” relationship indicates how a sensor pairs to a motor. In the diagram above, a Sensor

can only be paired with a motor; however, a motor can be paired with multiple sensors. This is an

important relationship to note as an encoder, for example, cannot be paired to more than one motor.

However, with that same logic, a temperature sensor and an encoder can both be paired to a single

motor to monitor various aspects of it.

50

Subsystems

Figure 31. The Component and Subsystem tables and their relationship

A subsystem is a part of the robot that performs some sort of task, like the digger mechanism. A

subsystem is made up of a unique ID, a name, and a description. As shown above, in Figure 31, a

component can only belong to one subsystem. However, a subsystem can have multiple

components. This is shown by the “Contains” relationship, which takes the ID of the component

and pairs it with the ID of the relevant subsystem. This allows for both high- and low-level views

to monitor the state of the robot by subsystem or as one system.

Trials Adding in a Trial table allowed saving historical data for debugging and improvement tracking.

Without a Trial table, data that was specific to a previous trial would be cleared each time at the

system started. A Trial is first composed of a unique ID, Type (Practice vs Competition), and a

Start Time. After the Trial, the Stop Time and Completion Status are then updated. By taking the

difference (delta) of the two times, it is possible to determine if the robot completed the intended

goals in the fifteen-minute time frame and if it had gotten better since the last trial.

51

Figure 32. The Run and Subsystem tables and their relationship

In addition to calculating the start and end time of the trial, keeping track of the trial times for each

subsystem was equally important. Since a subsystem could run multiple times in each trial, the

relation was kept as many-to-many, meaning that multiple trials could be linked to multiple

subsystems and vice versa (see Figure 32).

52

Message Relationships

Figure 33. Individual Components and their relationships

Keeping track of the runs and the times of each subsystem is important, but this alone is not

sufficient. This is where individual component tracking must be utilized. As shown in Figure 33,

everything is broken down based on the following component types: Battery, Camera, Motor, and

Sensor. The tables for each of these components, apart from the Sensor table, get a steady stream

of information. All the tables have three foreign keys assigned to them, except the Battery table

which has two, to relate the data in the tables to higher-level views. These foreign keys are the

Component ID, the Subsystem ID, and the Run ID. The Sensor table does not follow the same

style as the other three tables since there are different types of sensors that are present on

53

LOADER. Shown in the ERD subset in Figure 33, the IMU table uses the relationship “IsA” to

denote that it is a sensor. The “IsA” relationship denotes that an input is a certain type, such as a

sensor in this case. That table, along with any other sensor-typed table, is the table that will

continuously receive information.

54

Analysis

Development and Prototyping

For prototyping, designs were first modeled in SolidWorks to portray the current design as

accurately as possible. Prototypes were made with available materials that were laser cut and

assembled. The initial design that was created was for the excavation wheel and conveyor, which

was created out of wood Figure 35.

Figure 34. Laser-cut wooden prototype assembly

The purpose of the excavator wheel prototype was to allow for the angle of the conveyor's arm to

be changed. Two prototype buckets were designed and 3D printed, along with an internal insert to

allow for a change in angle to guide the collected material through the bucket Figure 35.

Figure 35. 3D printed internal insert for the prototype buckets.

55

The two plausible 3D printed bucket designs could be attached in up to four spots, and the angle

of the excavator relative to the ground could be altered from 0 degrees to 30 degrees with 2-degree

increments. As the angle increased the effectiveness of the passage of collected material increased.

The changing from a straight bucket to an angled bucket to match the excavator wheel angles

proved to be a vast improvement in both collection rate and amount (see Figure 36). This allowed

for a variety of test situations and data. Each bucket has different style teeth, angled head, and

intake opening. Videos were taken of each of the tests to show the different collection rates of the

buckets.

Figure 36. Prototype CAD Model of the 0-degree bucket (left) and 30-degree bucket (right).

Overall, this test method was successful in providing the team information about how much

material will be mined per revolution and the feasibility of the design. Unfortunately, the overall

lack of digging payload led to the elimination of the wheel and attachment of the digging buckets

to a conveyor belt instead.

56

After the design phase of the excavator conveyor, the CAD was updated to reflect the new

mechanisms involved and was further developed to support motion analysis. During the CAD

stage, component interactions were troubleshot; the center of mass properties were adjusted

through iteration; overall mass was calculated to ensure it was within limits; and the team modeled

all additional fasteners, tubing, and small parts that would be necessary.

To find the force required to dig through sand and rocks at the bottom of the digging conveyor, a

prototype (seen in Figure 37) was created. This consisted of two pieces of wood that were used for

the base and a third piece of wood with a bucket (from the previous team) secured with duct tape,

all connected with a single axle. The base wood pieces were used to secure the structure in the

sand, with the bucket-mechanism positioned to be able to collect a full load of material. To get the

force required, a spring scale was also attached to the central piece of wood. The bucket was

attached at two configurations: flat, and approximately 10 degrees. These configurations were

chosen to represent the two general orientations the buckets will be in when traveling around the

end of the conveyor belt. It was necessary to get these three different configurations as the force

required would vary, as seen in Table 4. The spring scale was located 314 millimeters from the

axle, and the tip of the bucket was located at three different distances, depending on the

configuration.

57

Configuration Distance

(mm)

Peak Force

Gage (N)

Peak Force

Calculated (N)

Steady Force

Gage (N)

Steady Force

Calculated (N)

Flat 101 11.5 36 3.2 10

Angled 143 4.5 9.7 1.2 2.6

Table 4. Distance from axel to bucket teeth in two configurations for digging conveyor testing, the average-

peak and steady forces read on the gage and the calculated forces at the bucket teeth.

Figure 37. Conveyor Excavator Prototype to calculate digging force in flat-bucket orientation (left), and a

closeup of the bucket at approximately 10 degrees (right).

Once the digging force was determined from the prototype, it was used to develop static analyses

on the bucket conveyor and four-bar mechanism. These analyses were used to determine the power

requirements needed from motors before ordering them, and also strength requirements for the

fasteners of the bucket on the pulley. The prototyping phase did not include every mechanism in

58

the robot, so the SolidWorks Analyses were a major part of showing how the mechanisms would

likely perform in real life. Overall, the analysis phase covered each aspect of the robot using either

real-life models or SolidWorks data and theoretical calculations.

Sinkage Calculations

Sinkage calculations were conducted to evaluate how deep the wheels would sink into the regolith

with the design. The result from these calculations were determined to be negligible, which

assisted in the determination of the wheel dimensions. The sinkage calculations used the following

equations: rigid wheel sinkage on the extraterrestrial surface, Becker pressure sinkage equation,

and Reece pressure sinkage equation (shown in Equation 10 and Equation 11 located in Error!

Reference source not found.). Error! Reference source not found. shows the results of the

sinkage calculations. The wheel dimensions were verified using the pressure sinkage equations.

Using the surface area from the wheel equation, as well as the properties of the regolith simulant,

the final acceptable sinkage for the overall design was determined. The sinkage turned out to be

so tiny, well under the ten-millimeter cutoff decided by the system requirements, that it was

determined to be negligible to the point it would not have to be considered unless the wheels would

rotate at an extreme speed.

59

Variable Number Units

Sinkage 1.10E-03 Meters

Mass on each Wheel 15 kg

The cohesion of Soil used 1 kPa

Table 5. Sinkage Calculation for Robot Wheels

Speed Calculations

The robot's speed is based on the size of the field (5.4 by 3.6 meters), the allotted time available

(fifteen minutes), and a conservatively estimated path taken (seen in Figure 38). The N-shaped

path was chosen to ensure the speed of the robot would be more than sufficient to navigate the

field, collect material, and deposit it in the given time limit. Although the robot would not travel

along the walls of the field, using these values add a factor of safety into the calculations as well.

Figure 38. Potentially longest path for robot navigation used to calculate robot speed.

60

To calculate the distance of the least optimal path is shown in Equation 2. The travel time of the

robot will be less than the fifteen minutes allotted, as there are two digging and two depositing

stages that will occur. If the time for travel is reduced to five minutes and with this path needing

to be completed four times, the speed at which the robot must travel to complete the N-shaped path

is 12.96 meters per minute (shown in Equation 3). Each lap would be completed in seventy-five

seconds, for a total of five minutes.

𝑑 = 3 ∗ 𝑤𝑖𝑑𝑡ℎ + 1 ∗ 𝑙𝑒𝑛𝑔𝑡ℎ = 3(3.6)𝑚 + (5.4)𝑚 = 16.2𝑚

Equation 2. Determining the distance taken based on Figure 38.

(16.2 m * 4) / 5 min = 12.96 m/min = 0.216 m/sec

Equation 3. The velocity required to complete the longest path in 5 minutes

Drive Base Calculations

To determine what motors would be used to drive the wheels, the torque required to move the

robot had to be calculated. A maximum mass of sixty-one kilograms was used for the entire robot,

including collected material, under the assumption approximately twenty kilograms will be stored

inside the containment bin after each digging phase. This assumed amount is likely to be greater

than what the robot will collect, acting as a factor of safety for these calculations to account for a

"worst-case" scenario. This puts the weight of the robot at approximately six hundred Newtons,

with a normal force acting on each wheel of one hundred fifty Newtons. From this point, it was

assumed the tractive force necessary to overcome the normal force would be twice the amount, at

three hundred Newtons. After establishing the known forces, the torque of the motor is calculated

using the free body diagram in Figure 39 and Equation 4.

𝜏 = 𝐹𝑡 ∗ 𝑟 = 300𝑁 ∗ 0.14𝑚 = 42𝑁 ∗ 𝑚 Equation 4. The torque required for drive base motor

61

Since each motor will be driving two wheels using the belt and pulley system, the force must be

doubled to eighty-four Newton-meters. After researching various motors and weighing the pros

and cons such as available torque, power draw, weight, and cost, it was determined that the ODrive

D6374 150KV motor was ideal. This is because it has a stall torque of 3.86 Newton-meters and is

directly compatible with the ODrive motor controller (which as previously mentioned works well

with ROS). Running this motor at 22 percent of its maximum capability would produce a torque

of 0.85 Newtons, and thus requiring a gear ratio of 1:100 to reach eighty-five Newtons.

Due to the lack of airflow that would exist on the Moon or Mars, the motors would heat up more

rapidly, rendering them less efficient. To give further confidence in the pairing of the ODrive

motor and motor controller, the controller limits the motor can take to help ensure it doesn't

overheat.

Figure 39. Free body diagram of torque required to drive one wheel.

62

Figure 40. Free body diagram of the top view of the chassis, use to calculate resultant friction force.

While the robot will not be executing turns directly about its center of mass, the force required to

do so provides additional insight into the torque required to drive the robot. Using the free body

diagram in Figure 40, the maximum resulting friction force (Ff) can be determined. When

considering the top left wheel, the greatest friction force is calculated to be about approximately

346 Newtons (using Equation 5 and the values in Table 6). If this value is used to determine the

torque required by the motor, a value of approximately ninety-seven Newtons is calculated.

Following the same procedure explained above, this would require the motor using a 1:100 gear

ratio to be run at 25 percent of its maximum capability. While this is above desired the desired

limit, the robot will still be capable of doing so if necessary.

63

𝐹𝑡2 + 𝐹𝑓

2 + 2𝐹𝑡𝐹𝑓(cos 𝜃𝑎) = 𝐹𝑟2 = 9000 + 𝐹𝑓

2 + 600𝐹𝑓(𝑐𝑜𝑠𝜃𝑎) = (𝐹𝑓 + 251)2 = −9000

𝐹𝑓 = −95 − 251 = −346𝑁

Equation 5. Calculation of resultant friction force, assuming no resistant force (Fr)

Variable Symbol Amount

Angle 𝜃𝑎 33.11

Tractive Force 𝐹𝑡 300 N

Resistant Force 𝐹𝑟 0 N

Resultant Friction Force 𝐹𝑓 -346 N

Table 6. Variables used to calculate resultant friction force.

Four-Bar Static Analysis

Two scenarios have been identified which could require a high amount of torque at the digging

motor. First, the torque required to keep the digger in the ground during the excavation period

would be significant due to the rough nature and high packing factor of the regolith simulant.

Second, the torque required for the motions of the digger into the ground and lifting the digger out

of the ground would need to be evaluated because it will be accelerating a large mass.

Using traditional static analysis of a free body diagram, forces at the joints of the four-bar

mechanism were calculated. This study used the maximum resultant force on the bucket teeth

measured during the prototyping stage. It was decided to show two buckets with this maximum

force at the same time because there is a point where both buckets are in the ground. The FBD is

shown in Figure 41 with the digging forces and unknown forces labeled in green.

64

Figure 41. Four bar free body diagram, summed around point D

65

Figure 42. Four bar link one free body diagram, summed around point A

Figure 43. Four bar link three free body diagram summed around point D

The set of equations in Table 8, using the values in Table 7, was extracted from the information in the

FBDs.

Variable L1 L2 L3 L4 L5 L6 L7 L8 L9

Length (mm) 97.99 518.38 422.38 171.48 203.75 48.99 250.20 198.40 214.38

Table 7. Four-Bar variable lengths (in millimeters)

66

Sum Variables

∑ 𝐹𝑥

= 0

𝐴𝑥 + 𝐷𝑥 − 𝐹1 − 𝐹2 ∗ 𝑐𝑜𝑠 (𝜃)

∑ 𝐹𝑦

= 0

𝐹2 ∗ sin(𝜃) − 𝐴𝑦 − 𝐷𝑦

∑ 𝑀𝑑

= 0

−𝐴𝑥 ∗ 𝐿1 + 𝐹1 ∗ 𝐿2 + 𝐹2

∗ cos(𝜃) ∗ 𝐿3 + −𝐹2 ∗ sin(𝜃) ∗ 𝐿4 + 𝐴𝑦 ∗ 𝐿5

+ 𝑀𝑑

∑ 𝐹𝑥

= 0

𝐴𝑥 − 𝐵𝑥

∑ 𝐹𝑦

= 0

−𝐴𝑦 + 𝐵𝑦

∑ 𝑀𝑎

= 0

𝐵𝑦 ∗ 𝐿7

∑ 𝐹𝑥

= 0

𝐷𝑥 − 𝐶𝑥

∑ 𝐹𝑦

= 0

𝐶𝑦 − 𝐷𝑦

∑ 𝑀𝑑

= 0

𝐶𝑦 ∗ 𝐿8 − 𝐶𝑥 ∗ 𝐿9 + 𝑀𝑑

Table 8. Equations of equilibrium for Four-Bar Free Body Diagram analysis

These equations were solved to find a torque Md in Newton-meters. The result is 23.87 Newton-

meters. Figure 59 in the Appendix shows the details of the matrix calculation performed.

67

Four-Bar Motion Studies

Two motion studies were conducted on the finalized CAD model of the four-bar system. One study

calculated torque on the motor while the digger was lowered into position, while the other

calculated torque on the motor when it was lifted back out of the ground. These were completed

in SolidWorks using a motor at 6 RPM and gravity settings for the five-second duration of each

motion. Figure 44 shows the settings for the studies.

Figure 44. Four bar motion study settings

From the motion studies, the following graphs were calculated to show torque at the motor over

time during each analysis. These are shown in both Figure 45 and Figure 46.

Figure 45. Four bar motion study one results

68

Figure 46. Four bar motion study two results

The highest amount of torque measured at any given time was about twenty Newton-meters when

the digger was lifted out of the ground, about two seconds into the study. From this, it was known

that the four-bar motor would need to be able to provide at least twenty Newton-meters of torque,

so the requirement was doubled to include a safety factor of two. Compared to the maximum torque

calculated during the static analysis with maximum digging forces, this torque is slightly lower

(20 Nm < 23 Nm), therefore a motor that supports at least twenty-three Newton-meters is required.

Digging Bucket Static Analysis

A possible critical failure point identified on LOADER is at the fasteners connecting the digging

buckets to the conveyor. Two free body diagrams (FBDs) are shown below, depicting the forces

acting on a bucket (see Figure 47 and Figure 48). These diagrams are used to solve for the resultant

forces applied. This analysis uses the digging force found during the prototype stage, which was

forty-five Newtons.

The digging force applied at the tip of the buckets simulates the absolute maximum torque. The

FBDs with the forces at the fasteners are shown in Figure 47 and Figure 48.

69

Figure 47. Bucket forces free body diagram, summed around point A

70

Figure 48. Bucket forces free body diagram, summed around point B

From the FBDs and variables in Table 9, the following equations in Table 10 and Table 11 were

extracted:

Variable L1 L2 L3 L4 L5

Length (mm) 34.87 54.48 9.93 3.25 16.00

Table 9. Lengths from bucket free body diagrams

71

Sum Variables

∑ 𝐹𝑥 = 0 𝐵𝑥 − 𝐹1

∑ 𝐹𝑦 = 0 𝐴𝑦 + 𝐵𝑦

∑ 𝑀𝐴 = 0 𝐵𝑦 ∗ 𝐿1 + 𝐹1 ∗ 𝐿2

Table 10. Equations of Static Equilibrium for bucket free body diagram, summed around point A

Sum Variables

∑ 𝐹𝑥 = 0 𝐵𝑥 − 𝐶𝑥

∑ 𝐹𝑦 = 0 𝐵𝑦 + 𝐷𝑦 − 𝐶𝑦

∑ 𝑀𝐵 = 0 𝐶𝑦 ∗ 𝐿3 + 𝐶𝑥 ∗ 𝐿4 − 𝐷𝑦 ∗ 𝐿5

Table 11. Equations of Static Equilibrium for bucket free body diagram, summed around point B

These were solved to get a pull-out force (Cy) of 160 Newtons. This would be distributed amongst

four screws, resulting in a value of forty Newtons. Then, this was compared to the specifications

given by Brecoflex in Figure 49.

Figure 49. Allowable Forces per Insert in N (Perpendicular to Belt Surface

72

It is shown that the allowable force is much greater than the calculated maximum force, even with

a safety factor of two.

Passive Conveyor Lift Calculations

The forces needed to passively lift the conveyor using a sealed-gas piston were calculated to

determine the greatest amount possible. This occurs when the conveyor is at it's starting position,

as the angle of the piston is the lowest at twenty degrees. The weight applied to the attachment

point, as shown in Figure 50, was conservatively estimated to be five kilograms. When the

conveyor approaches the highest point along the guiding rail, it is assumed this weight will be less

and done so to ensure the piston could lift the convey at every point.

Figure 50. Free body diagram of the attachment point of the conveyor piston

Forces F-Force Of Piston

broken into Fx & Fy

W-Force of Conveyor due

to gravity

Ff: Normal Force Ff: Force of friction

Equations 𝐹𝑦 = 𝐹 ∗ 𝑠𝑖𝑛(20)

𝐹𝑥 = 𝐹 ∗ 𝑐𝑜𝑠(20)

𝑊 = 5𝑘𝑔 ∗ 9.81 = 49𝑁 𝐹𝑛 = 𝐹𝑥 𝐹𝑓 = µ𝑓 ∗ 𝐹𝑛

Table 12. Values for Gas Springs on Conveyor

73

Using Equation 6 below and Table 12 above, the force F is broken up to Fy and Fx, the force found was

approximately 662 Newtons, which takes into account the friction coefficient between the two aluminum

pieces of 0.3. This requires each piston to exert about 350 Newtons of force. The CAD model was used to

determine the length of the piston, which must start at 202.37 millimeters when compressed, and reach

336.45 millimeters when extended. To fulfill these requirements, a custom piston is needed - which could

be purchased from Industrial Gas Springs (IGS).

𝐹𝑦 = 𝐹𝑓 + 𝑤 → 𝐹 = 661.14𝑁

Equation 6. Force required for the passive piston to life the deposit conveyor.

Material Collection Calculations

To determine the amount of regolith simulant collected, both the digging and depositing

subsystems needed to be considered. The amount of material the digging subsystem is capable of

collecting was determined by the number of buckets, the volume they can contain, the speed the

system operates at, and the length of operation time. With ten buckets, having a volume of

approximately 2.61 × 10−4 cubic meters, the robot can collect about 2.61 × 10−3 cubic meters of

material per rotation. The material goes through two stages of sifting discussed above.

It is estimated that the containment bin can store at least four kilograms of icy regolith without any

mounding of material. This is a very conservative estimate where no material has any possibility

of falling out during driving. Assuming that the collection picks up two-parts regolith and one-part

icy regolith. Three full rotations of the digging mechanism would be required to collect the

estimated four kilograms of depositing material.

Power Consumption

One of the requirements of the challenge was to include technical performance measurements in

the Systems Engineering paper (Bimonte, et al., Systems Engineering Paper, 2020). A power

budget was created for the robot, as seen in Table 13, assuming a maximum power draw for each

74

component during the fifteen-minute run time. This budget represented a worst-case scenario,

allowing the team to create a power subsystem that would have a sufficient power reserve to

complete the competition. This worst-case power consumption was based on the known power

consumption of the electronics components from their respective datasheets. The watt-hour usage

for the operational time was done by calculating the voltage and amperage used (which determines

watts), multiplied by the amount of time the motor operated for the challenge. The actual total

consumption shall be found during verification testing. Once the robot is assembled and tested in

a simulated environment, a “Commercial Off-The-Shelf” (COTS) electronic data logger device

shall be used to monitor and record power consumption.

Table 13. Power Budget for LOADER

Power Budget (15min run time x 2 complete dig and offload runs) = 0.25 hour

Element Component Estimated(Wh) Operational Time (Wh) Total Wh

Base

Wheel Motor x 2 24V x 120A x 2 4320 x .083h (75% ave of peak amps) 359 Wh

Payload

Excavator Motor 12V x 40A 489 x .133h 64 Wh

Four Bar Motor 12V x 17A 204 x .100h 20 Wh

Offload Motor 12V x 29A 348 x .033h 11.6 Wh

Electronics

Controller 5Vx4A x 0.25h 5 Wh

CPU RasPi 4 + Jetson (5Vx1A)x 5 x 0.25h 6 Wh

Router 3.9watts x 0.25h 1 Wh

Camera x 2 5Vx0.7A x 0.25h 0.9 Wh

Total Consumed Power 467.5 Wh

Total Battery Output 12V x 22Ah x 2 24V x 22 Ah 528 Wh

Margin 60.5 Wh

75

Heat Dissipation

Heat management is a critical design consideration because poor heat management can cause

electronic components to fail. Operational temperatures will be a determining factor in the

longevity and success of LOADER. The most heat-sensitive component in the system is the

NVIDIA Jetson Nano. The Nano has a maximum operating temperature of 97℃. The electronics

are enclosed to keep out conductive dust and any matter that may interfere with the more sensitive

components. Without further heat management, the board will overheat and lose functionality. A

typical passive heat sink relies on two properties to dissipate heat: natural convection and radiation.

For the team’s theoretical application, the only property active will be radiation because there will

be no natural convection on celestial bodies with little to no atmosphere. Due to the extraterrestrial

conditions the competition is based on, the emissivity of the materials should be considered.

Emissivity is a material's ability to emit heat via radiation. The overall goal is to radiate the most

heat off the external material of the electronics box while transferring as much heat as possible to

the external surface from the components.

To interface the junction, or heat-producing element, to the case, there must be an intermediate

conductor called a heat spreader. The diagram for heat resistance of every material involved is

shown in Figure 51.

76

Figure 51. Heat Sink Flow Chart

In the above graph, resistance at each interface is considered. Between the junction heat spreader

and heat sink, there is a thermal interface material (TIM). The connection between the components

and the TIM results in thermal resistance, and when summed gives the total resistance of the

system. The calculated goal resistance of the system is 6.2 Celsius/Watt. This value is given by

Equation 7.

Ø =𝑇𝑀𝐴𝑋−𝑇𝐴𝑚𝑏

𝑃𝑜𝑤𝑒𝑟

Equation 7. Goal Heat Resistance of the System

The team built in a safety factor of 4℃ to account for onboard sensor variation and load variation.

Both the temperatures on the Moon and Mars vary so greatly that the team decided to use the

average temperature in Florida during the month of the competition, 31°C, as the ambient

temperature in the above calculation. Thermal interface material is chosen based on their thermal

resistance, calculated by Equation 8:

𝑅𝜃 =∆𝑥

𝐴 × 𝑘

Equation 8. Thermal Resistance from Conduction

77

The equation gives the thermal resistance of an object given its size and thermal conductivity.

When choosing thermal interface materials, thermal resistance plays a major role in the efficacy

of the interface, but there are several other considerations. First, the connection the interface

material makes to the junction or heat spreader is extremely important to the longevity of the

system, and its heat transfer efficiency. The connection not only needs to be preserved during

operation but also during deployment, transportation, and assembly. This leaves room for human

error when assembling the heat sink. There are many choices of interface material ranging from

thermal paste to thermal pads. The thermal resistance of the materials is so low that the main

considerations are longevity and ease of application. The team determined that thermal pads would

be used for the thermal interface material. Their resistance using the previous equation is 0.02

Celsius/Watt. The heat spreader will be determined by its ability to minimize heat loss via

radiation, and span the gap between the top of the enclosure and the junction. Finally, the external

material that interfaces with the outside environment should maximize emissivity with the surface

of Mars and the Moon in mind. A typical material for this purpose is anodized aluminum alloys

that can reach 0.9 emissivity while minimizing weight. In a successful competition trial, the system

will stay below the maximum thermal resistance specified earlier in this section.

Database Size

The space of the database had to be considered when monitoring all the components and

subsystems of LOADER. Using an eight-byte header for each of the records and assuming eight-

byte boundaries, the following formula was used to calculate the size of each row (Equation 9).

𝑅𝑜𝑤 = 8 + ∑ 𝑟𝑜𝑢𝑛𝑑 (𝑠𝑖𝑧𝑒(𝑐𝑜𝑙𝑥)

8) × 8

𝑦

𝑥=1

Equation 9. The equation to figure out the size of a row.

78

It is to be noted that the variable-length fields were treated as fixed-length fields for the ease of

calculation. In Table 14 below, the size of each row is calculated per each table and multiplied by

the number of unique rows. Tables that receive constant messages are then multiplied by 900 to

represent the number of seconds in a trial. Finally, the size in bytes is converted to megabytes

using a conversion factor of 1 MB to 220 B.

Table 14. Amount of data collected per a table and over twenty runs

Risk Mitigation The environment of regolith mining brings many risks to the functionality of a robotic mining

system. A table of the pertinent risks, failure modes, root causes, and their mitigations are shown

in Error! Reference source not found. below. If a part failure type event occurs during a test or

competition, replacement parts can be easily obtained from the LOADER spare parts inventory.

Major threats to mission success can be mitigated through proper verification testing of system

performance. A list of planned system validation tests can be found in Section 5.13.

79

Function Failure Potential

Effects

Root Cause Mitigation

Base motion Robot tips Mission failure Center of mass

moves to high

Test for ideal

path & speed

Base motion Wheels sink

into regolith

or lose

traction

Mission failure Low coefficient of

Regolith friction

or to high speed

Calculate wheel

loads and add

paddles to wheel

Gear

contamination

Components

of Gearboxes

degrade

Mission failure Regolith degrades

components with

repeated wear

Visual

inspection and

dust shields

Frame

deformation

or breakage

Fracture or

bending

Threat to

Mission success

or failure

Tensile forces on

members are too

large

Stress analysis

and functional

testing

Motor Motor burns

out

Mission failure Excessive load on

the motor causing

high current draw.

Motor controller

with encoders to

prevent stalling

Base motion A drive belt

slips off

Threat to

Mission success

or failure

Belts lose tension

or debris gets

between belt and

pully

Vex tensioner

testing and dust

enclosure

Collection

conveyor

Bucket

separates off

the conveyor

belt

Threat to

Mission success

Strikes

hardpacked rock

causing excessive

load

Hinge design

releases bucket

upon damage

Electronics Disconnected

wires

Mission failure Jostling of robot

causes connectors

to disconnect

Install locking

connectors and

zip tie harness

Software Software bugs

or resets

Threat to

Mission success

Error during

programming

Testing at

component and

functional level

Software Autonomy

malfunction

Loss of

autonomy

points

Sensor

malfunction,

orientation loss

Testing and

redundant

camera’s

Electronics Communicati

on failure

Threat to

Mission success

Poor connection,

packet loss, power

glitch

Watchdog timer

to reset the

connection Table 15. Risk Mitigation Table for each problem

80

Validation Testing

Validation Testing is a component of the required Systems Engineering paper (Bimonte, et al.,

Systems Engineering Paper, 2020). This is the process of real-world testing, under realistic (or

simulated) conditions, and is done using the end product – as opposed to testing the robot while

verifying subsystems work. It also is to determine if the intent of the stakeholder (being NASA)

has been met.

The Excavation System Validation Testing will consist of testing the built-in mass detection

systems by excavating four kilograms of simulated material and storing it in the collection bin.

The time required to fill the bin will be recorded for the collection of both one and four kilograms

of simulated material trials. These resultant values will be used to validate the competition

timeline.

The Depositing System Validation Testing will involve extending and retracting the depositing

conveyor three times, recording the time to reach max height. The containment bin will be filled

with four kilograms of silica sand, operate the depositing conveyor, and record the time required

to empty the bin. The resultant value against an estimated time in the competition timeline will be

verified.

The Base Subsystem Validation Testing will include autonomous and manual operation. The Tele-

operation System Validation will operate the robot in teleoperation mode in a physically simulated

environment, to confirm its abilities in navigation, deployment of all subsystems, excavation, and

depositing material. The robot’s ability to traverse obstacles with and without material in its bin

will be observed. The robot will be operated in this simulated environment while functionally

testing all subsystems for fifteen minutes and carrying maximum regolith. The test will then be

repeated for an additional fifteen minutes to verify the capability of two runs from the same battery

81

pack. Upon successful completion of manual teleoperation control, the team will proceed with

Autonomous Systems Validation. The Autonomous Systems Validation will operate the robot in

the same physically simulated environment to confirm its ability to autonomously navigate,

excavate, and deposit material.

Validation Testing was to occur at Cape Canaveral’s lunar simulation test site. However, this event

was canceled due to the COVID-19 pandemic.

82

Project Organization

Scrum

Scrum is a framework for managing complex bodies of work across multiple teams. Originally

designed for software development, it created a quick and concise method to address progress and

problems efficiently between members. In the Scrum project management framework, the whole

team held dedicated meetings to discuss updates to current projects. These meetings involved each

member speaking about the progress on current projects, the work needed to be completed on said

projects, and any blockers encountered. A blocker is an obstacle preventing progress on a project.

A dedicated Scrum Master recorded notes of each update to properly track progress. Once all team

members had completed their project updates, the team discussed the blockers people had

encountered. This discussion allowed for multiple options and views to be considered to eliminate

any blockers. In addition to these daily meetings, tasks were broken up into two-week segments,

called a sprint. Once the sprint is completed, the team re-evaluated the current plan of the project

to decide what needed to be completed for the next sprint. This included an analysis of what was

and was not working, what needed to be changed with respect to the projects that needed to be

completed, and where further focus was required.

The Scrum framework was chosen as it allowed the interdisciplinary team to easily collaborate

with ideas, ask cross-discipline questions, and evaluate what the current needs were between each

Scrum meeting. Scrum provided the communication outlets necessary for a large and complex

project and allowed team members to quickly eliminate blockers before becoming major obstacles.

83

Product Breakdown System (PBS)

When working on the CAD design for the robot, a process was required to keep track of what

items are needed and the collective weight of the entire system, as well as the individual

subsystems. A Product Breakdown System is a spreadsheet that individuals update as the CAD is

being completed. This system also tracks the type of object (assembly, part), the build (manual

machining, 3D, off the shelf, etc.), the quantity, the CAD status, the part status (ordered, ready to

be ordered, etc.), and the owner of the assembly or part. Figure 52 shows an example of the highest

to lowest level breakdown of the system, with the LOADER system being the main, with the base

as a first-tier subsystem, which includes a second-tier subsystem – the frame, which includes

individual parts. This was a useful tool as it helped keep track of components but also progress

overall.

Figure 52. Example of PBS, breakdown of systems, subsystems, and parts.

Cost Plan

To further determine the feasibility of the overall design of LOADER, a cost plan was developed.

To create an adequate plan for the project, three primary components were taken into

consideration: the cost estimate, the budget, and cost controls (Weedmark, 2019). First, the cost

estimate determines what the projected cost of building the robot is, as well as the travel cost

84

required to participate in the Lunabotics competition. Next, the project budget is simply the budget

available for the project, this consists of funds given allotted to the team by WPI, as well as the

remaining budget from the previous year. Finally, the cost controls dictate how the budget and

estimated cost are monitored, and the specifics of any pricing guarantees given to the team by

supplies for instance.

The overall cost estimate was tracked throughout the project in a Cost Plan Budget and Material

List, utilizing Google Sheets. This contains all of the necessary items to build the robot (which are

separated into sections by type), cost, amount, total cost, ordered date, received date, and a link to

where it can be purchased (see Figure 53). This tracking system allowed the team to keep track of

what was ordered and when, where it was purchased from, and maintained a running total of what

was spent. This sheet did not include the cost of manufacturing, travel, nor accommodation costs

which would have been necessary for the team, had the competition not been canceled due to the

Coronavirus pandemic. An estimate of these cost including a rough estimate of what the full robot

would have cost is located in the Systems Engineering paper (Bimonte, et al., Systems Engineering

Paper, 2020). The manufacturing costs were to include the cost accrued for manufacturing done

outside of WPI, such as for water jetting pieces, or creating custom parts. The travel and

accommodations costs were determined to consist of the cost of plane tickets, the estimated cost

of gas for transporting the robot, the cost of an Air B&B for the team.

85

Figure 53. Example of the material order list, showing the section of the electronic components.

The budget included the combined amount each student was stipend by WPI, outside contributions,

and would have considered sponsor donation and money made from recycling old parts. The

budget can be seen in Table 16. The WPI stipend has a variable amount depending on the type of

major for each student on the team; Computer Science majors received one hundred dollars each,

and both the Mechanical and Robotics Engineering major received two hundred fifty dollars each.

A sizable contribution was made by Mike Caradli, who was one of the lead advisors for previous

NASA RMC MQPs, which was money raised and leftover from the previous year's project. There

were, unfortunately, no sponsor donations nor funds received from recycling due to the

coronavirus pandemic.

86

Total Budget: $14,351.41

Type Amount Value Amount Contributed

WPI Stipend

6 $ 1,050.00

Computer Science $100.00 3 $ 300.00

Mechanical Engineer $250.00 1 $ 250.00

Robotics Engineer $250.00 2 $ 500.00

Previous Year's Budget

1 $ 13,301.41

NASA RMC 2018-2019 $ 13,301.41 1 $ 13,301.41

Sponsor Donations

0 $ -

Recycled Returns

0 $ -

Table 16. The budget from the cost plan, showing all contributions.

The cost control dealt with monitoring orders and the budget, ordering materials, and determining

how those were handled. The order sheet was checked twice a week for new requests on Monday

and Thursday unless explicitly specified by a team member that a part needed to be ordered. The

amounts needed of a specified item was factored into the total cost, meaning two items for ten

dollars was twenty dollars. When orders were made a box was checked to denote it was ordered,

and the date of the order was entered. This was also done when items were received. To ensure

that the orders did not go over budget, an overestimated amount was set as the total spent, with a

running total included subsequently. The amount to be overestimated is dictated in the specified

column, to also account for tax and shipping. This was set to be ten percent but could be changed

at any time.

87

Social Implications

As the Earth faces an ever-approaching worldwide depletion of natural resources, alternative

sources of energy must be recognized and utilized. With this resource crisis, the planet also faces

an ever-worsening climate change disaster and a global pandemic that may never be resolved (BBC

News, 2020). Using renewable energy sources can potentially alleviate some pressures of these

issues and mitigate the exasperation of them as overall problems. The following sections detail

some of the factors needed when considering each source as a viable option, as the risks may

surpass the overall benefit.

Renewable Energy Sources

Using non-renewable resources can be very dangerous to the environment. Alongside this fact,

transporting materials outside of Earth's orbit is extremely expensive. If an energy source is

available at the destination of a space-faring craft, the overall cost of transportation and missions

can be greatly reduced. Renewable energy sources, including solar panels and wind turbines, are

used on Earth. They have not, however, been tested on different planets. Icy regolith, the primary

focus of the NASA Lunabotics challenge, will also be investigated regarding this topic.

Unfortunately, due to this being outside of the scope of this project, these will not be tested or

analyzed directly during the project, although they are detailed in the report.

Regolith as Fuel The primary use of the icy regolith that will be mined from the surface of the moon is as an energy

source. Due to its composition of hydrogen and oxygen, this regolith has the potential to make

rocket propellant. While burning this energy source will have an environmental impact, it has been

shown to be safer than current rocket fuel - which contains aluminum and ammonium perchlorate.

Burning aluminum as a fuel produces perfluorocarbons (PFC) and carbon dioxide (CO2), among

88

other greenhouse gases, which contribute to emissions (Columbia Climate Center, 2012).

Hydrogen has significantly lower greenhouse gas emissions. Even when used as a biogas blend,

there is a reduction of carbon monoxide emissions up to 30% when compared to diesel fuel

combustion (Bouguessa, Tarabet, Loubar, Belmrabet, & Tazerout, 2019). The burning of hydrogen

also produces heat, which can be further used as an energy source when stored in fuel cells

relatively similar to a steam turbine.

Since access to icy regolith is readily available on the surface of the Moon, this makes it a viable

candidate as a fuel source. The way in which it is converted from a solid form into an energy source

requires the use of microwaves, which doesn't appear to have any (significant or otherwise)

negative impacts on the environment compared to a typical combustion engine.

Table 17 offers a direct comparison between fuel cells and four other types of common power

sources.

89

Property Fuel cell Gasoline engine

Diesel engine

Battery Gas turbine

Fuel efficiency potential E G G E F

Present and near-term fuel efficiency

F F G E F

Ability to deliver good fuel efficiency with varying loads

E F F E P

Will work with a variety of fuels F E E P E

Power output per system weight

G G G P E

Engine cost per power output P E G F G

Durability and expected performance life

I F G F E

Emissions at vehicle E G F E G

Emissions not a vehicle F E E G E

Feasibility of practical rechargeable systems

E P P E P

Performance synergy with hybrid vehicles

E G E E G

Lack of hidden performance problems

P E E E E

Table 17. Performance strengths of different mobile power sources (Suppes & Storvick, 2016).

E, excellent; G, good; F, fair; P, poor; I, insufficient data.

If icy regolith can be mined from the surface of the Moon, or Mars, to be used as an energy source,

the cost to transport critical materials from Earth would be significantly reduced. Since the ratio

of propellant to structure for a rocket is 96:4 (Pettit, 2012), this means transporting an energy

source as a payload (and not fuel) would require its "own" propellant. On the other hand, if that

90

energy source is not required and be obtained at the destination, less over propellant is required -

or propellant can be used for something more important.

Additional Sources Besides icy regolith, energy can be generated from other sources that have been tested and utilized

on Earth. Solar panels and wind turbines are effective sources of energy, although less efficient

when compared to fuel-based combustion or steam-turbine nuclear generators. The reason these

are less efficient is due to the phases required for conversion from the source to the energy. With

a solar panel, for instance, photovoltaic cells absorb photons from sunlight which essentially

creates an electrical charge that transfers through the cell to then be used as energy (Knier, 2008).

This process generates heat which is not entirely utilized, reducing the efficiency of the entire

system. This does not produce harmful emissions. Solar panels also require less environmental

disruption to create compared to the mining and refining of fossil fuels. While there are

environmental impacts caused through the manufacturing of these cells, it is shown that "the most

intensive mainstream solar power emits less than one fourth the life cycle greenhouse gas

emissions from the least carbon-intensive mainstream fossil power (Miller, et al., 2019)“.

Wind-generated power also comes with its own environmental impact, but these drawbacks can

largely be disregarded if being installed on Mars. The primary impacts of wind-generated power

are the death of wildlife and noise pollution (Saidur, Rahim, Islam, & Solangi, 2011). Since it

utilizes energy that would otherwise be wasted, it would have its place as viable sources. Alongside

the frequent wind storms on Mars, this type of generator could potentially serve as excellent, non-

carbon emitting energy sources. The main drawback of using wind and sunlight to generate energy

is with the manufacturing, transportation, and construction of the necessary structures. The parts

would need to be made on Earth, depleting resources, and the transportation would completely

91

remove the resources from the planet and require resources to ship. Finally, constructing the

turbines would require an entirely different set of robots than the main focus of this paper. This

comes with its own environmental impacts as well.

92

Conclusion

Creating a fully autonomous, sub-60-kilogram excavating robot is a complex task that requires an

understanding of both physical and virtual platforms. Referencing past projects and various

resources on campus was important to not only meet the base goals of the project, but adapt them

to restrictions created due to the COVID-19 pandemic. The nature of the design made two areas

of the team (software and hardware), which were demonstrated by the scope of this project.

To give the robot the best chance at success in the Lunabotics competition, a complete redesign of

all mechanical components was necessary. This meant research, design, prototyping, and

optimization for excavating and depositing systems, drive train, and more. With the help of virtual

tools, the extensive design plan was completed. On the software side, instead of building off

previous years’ code, the team elected to overhaul the code using a variety of different software

packages.

Based on the findings from this project, a few recommendations were realized for the subsequent

teams that undertake this project. In the future, the entire team should include equal amounts of

Mechanical, Electrical and Computer Engineering, Robotics, and Computer Science majors. This

will allow all members of the team to have knowledge of specific sub-sections on the robot. Future

teams should focus on improving the existing robot and codebase instead of redesigning unless

competition rules dictate it. The process of designing and building a new rover may be enjoyable

but may be out of the scope and time for a team of six. Keeping this in mind will allow more work

to be done on improving the robot instead of recreating it.

Despite the cancellation of the 2020 NASA Lunabotics Challenge, the team was able to take

advantage of virtual tools and data from earlier terms to create a design plan suitable to be built.

93

Design considerations, extensive analysis, SolidWorks modeling, and software development can

prepare future teams to compete with an award-winning robot.

Future Work

Due to many setbacks this year from the late release of new information on the competition to the

outbreak of COVID-19, there are many aspects of the project that can be improved upon or

completed. The robot was not able to be fully built due to the pandemic, but the base was set up

and organized accordingly for the future team to be able to begin construction. A bill of materials,

which includes custom parts such as belt and pully from BrecoFlex, must be ordered before

construction of the robot. The Systems Engineering paper has been organized and must be thought

about earlier in the project. All hardware must be rigorously tested as discussed previously in the

verification planning (see 5.13). The funding provided was rarely used this year as shown in Table

16.

There are also many aspects of the software aspect of the robot that can also be improved upon.

The pandemic prevented the team from using some of the physical hardware for the robot, which

made it impossible to fully set up the software environment with the proper communication

methods. Future teams will need to connect the individual aspects of the system to ensure proper

communication via the communication channels mentioned in Section 4.3 (see Communication).

This fully configured environment will also need to be thoroughly tested with a more detailed

timing analysis. The database system, which is currently being hosted on AWS, will need to be

migrated to a local MySQL instance on the robot since there will be no internet connection during

the competition. Lastly, since the team focused on autonomy for additional points in the

competition, teleoperated control methods need to be implemented, both for testing and possible

competition use.

94

The next team will also need to manage the physical parts gathered throughout this project. First,

while most electronic parts for the robot were documented and ordered, other parts such as

additional sensors and a power distribution board need to be ordered. All electronics must also be

wired following the electronics diagram in Section 4.2. Lastly, there are scraps of metal that cannot

be used for LOADER that have accumulated throughout this project. Recycling these scraps can

raise more money for the total project as well as protect the environment.

95

Bibliography

Australian Broadcasting Corporation. (2014, January 25). China's moon rover, Jade Rabbit, has

'abnormality': state media. Retrieved from Australian Broadcasting Corporation:

https://www.abc.net.au/news/2014-01-25/an-china27s-moon-rover2c-jade-rabbit2c-has-

27abnormality27/5218986

Barbosa, R. C. (2013, December 14). China’s Chang’e-3 and Jade Rabbit duo land on the Moon.

Retrieved from NASA Spaceflight: https://www.nasaspaceflight.com/2013/12/china-jade-

rabbit-lunar-arrival/

Barlas, F. (2004, June). Design of a Mars Rover Suspension Mechanism . Retrieved from Izmir

Institute of Technology:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.538.6955&rep=rep1&type=pdf

BBC News. (2020, 05 14). Coronavirus may never go away, World Health Organization warns.

Retrieved from BBC News: https://www.bbc.com/news/world-52643682

Bimonte, K., Burack, H., Freedman, C., Hogan, J., Hogan, M., & Kuberka, N. (2020). Software

Sequence Model. Worcester: Worcester Polytechnic Institute.

Bimonte, K., Burack, H., Freedman, C., Hogan, J., Hogan, M., & Kuberka, N. (2020). Systems

Engineering Paper. Worcester: Worcester Polytechnic Institute.

Bouguessa, R., Tarabet, L., Loubar, K., Belmrabet, T., & Tazerout, M. (2019). Experimental

investigation on biogas enrichment with hydrogen for improving the combustion in diesel

engine operating under dual fuel mode.

Brooks, C. A., Iagnemma, K. D., & Dubowsky, S. (2006, April 22). Visual wheel sinkage

measurement for planetary rover mobility characterization. Retrieved from Massachusetts

96

Institute of Technology:

https://scripts.mit.edu/~robots/robots/publications/Iagnemma_Auton_06.pdf

Brunskill, C., Patel, N., Gouache, T. P., Scott, G. P., Saaj, C. M., Matthews, M., & Cui, L. (2010,

December 4). Characterisation of Martian Soil Simulants for the ExoMars rover testbed.

Retrieved from CORE: https://core.ac.uk/download/pdf/397902.pdf

Cai, M. (2011). In Rock Mechanics: Achievements and Ambitions (p. 168). CRC Press.

Caplinger, M. (1994, September). Seasons on Mars. Retrieved from Malin Space Science Systems:

https://www.msss.com/http/ps/seasons/seasons.html

Choi, C. Q. (2017, September 8). Moon Facts: Fun Information About the Earth's Moon. Retrieved

from Space.com: https://www.space.com/55-earths-moon-formation-composition-and-

orbit.html

Climate Central. (2009, November 7). What is the greenhouse effect? Retrieved from Climate

Central: https://www.climatecentral.org/library/faqs/what_is_the_greenhouse_effect

Columbia Climate Center. (2012). Mitigating Emissions from Aluminum. Columbia University.

Curt, F. (1952, January 2003). United States Patent No. US2705379A. Retrieved from Google

Patents: https://patents.google.com/patent/US2705379A/en

CustomPartNet. (n.d.). Drilling Horsepower Calculator. Retrieved from CustomPartNet: Widgets:

https://www.custompartnet.com/calculator/drilling-horsepower

Dunbar, B. (2019). Apollo’s Legacy Is NASA’s Future. Retrieved from NASA Apollo 50th:

https://www.nasa.gov/specials/apollo50th/back.html

Dunbar, B. (2019, July 25). What is Artemis? Retrieved from NASA: https://www.nasa.gov/what-

is-artemis

97

Dunbar, B., & Greicius, T. (2012, November 2). The Five Most Abundant Gases in the Martian

Atmosphere. Retrieved from NASA:

https://www.nasa.gov/mission_pages/msl/multimedia/pia16460.html

Flinn, E. D. (2006, February 23). Solving Settlement Problems: Dealing with Moon Dust.

Retrieved from Space.com: https://www.space.com/2079-solving-settlement-problems-

dealing-moon-dust.html

Gertsch, L. S., Rostami, J., & Gustafson, R. (2008). Review of Lunar Regolith Properties for

Design of Low Power Lunar. Retrieved from Scholars' Mine:

https://scholarsmine.mst.edu/cgi/viewcontent.cgi?article=2932&context=icchge

Goddard Space Flight Center. (2009). Lunar Reconnaissance Orbiter. Retrieved from Goddard

Space Flight Center: Lunar: https://lunar.gsfc.nasa.gov/about.html

Gray, B. (2012, August 25). Chang'e 2: The Full Story. Retrieved from The Planetary Society:

https://www.planetary.org/blogs/guest-blogs/20120825-change-2-the-full-story.html

Heiney, A. (2017, August 9). RMC Archive. Retrieved from NASA:

https://www.nasa.gov/content/rmc-archive

Heiney, A. (2019, May 30). RMC Archive 2019. Retrieved from NASA:

https://www.nasa.gov/content/rmc-archive-2019

Heiney, A., & Johanboeke, R. (2018, March 23). RMC Icy-Regolith Simulant. Retrieved from

NASA: https://www.nasa.gov/image-feature/rmc-icy-regolith-simulant

Indian Space Research Organisation. (2019, September 7). Chandrayaan - 2 Latest Update.

Retrieved from Indian Space Research Organisation: https://www.isro.gov.in/update/07-

sep-2019/chandrayaan-2-latest-update

98

Jin, Y.-Q., & Fa, W. (2007, September). Quantitative estimation of helium-3 spatial distribution

in the lunar regolith layer. In Icarus (pp. 15-23). Elsevier Inc. Retrieved from

https://www.sciencedirect.com/science/article/abs/pii/S0019103507001285#!

Jones, A. (2018, December 19). Chang'e-4 lander makes contact with Queqiao relay satellite from

lunar orbit. Retrieved from gbtimes: https://gbtimes.com/change-4-lander-makes-contact-

with-queqiao-relay-satellite-from-lunar-orbit

Knier, G. (2008, August 6). How do Photovoltaics Work? Retrieved from Nasa Science:

https://science.nasa.gov/science-news/science-at-nasa/2002/solarcells

Lakdawalla, E. (2018, November 9). Map of all Mars landing sites, failed and successful.

Retrieved from The Planetary Society: https://www.planetary.org/multimedia/space-

images/charts/mars_landing_site_map_lakdawalla.html

Liu, J., Gao, H., & Deng, Z. (2008). Effect of Straight G rousers Parameters on Motion

Performance of Small Rigid Wheel on Loose Sand. Information Technology Journal,

1125-1132.

Mahroos, I., Hassan, M., & Shaaban, O. (2011). Extended Kalman Filter Simultaneous

Localization And Mapping.

Meirion-Griffith, G., & Spenko, M. (2010, September 30). A New Pressure-Sinkage Model for

Small, Rigid Wheels on Deformable Terrains . Retrieved from Semantic Scholar:

https://pdfs.semanticscholar.org/ad2d/e53671437959423cdcb48fe6297441007384.pdf

Miller, I., Gencer, E., Vogelbaum, H. S., Brown, P. R., Torkamani, S., & O'Sullivan, F. M. (2019,

January 12). Parametric modeling of life cycle greenhouse gas emissions from photovoltaic

power. Retrieved from

https://www.sciencedirect.com/science/article/abs/pii/S0306261919300133

99

Moreland, S., Skonieczny, K., Inotsume, H., & Wettergreen, D. (n.d.). Soil Behavior of Wheels

with Grousers for Planetary Rovers. Retrieved from Carnegie Mellon University: The

Robotics Institute:

https://www.ri.cmu.edu/pub_files/2012/3/2012_IEEE_Aero_Moreland_REVb.pdf

NASA. (2018, November 26). InSight’s Landing Site: Elysium Planitia. Retrieved from MARS

InSight Mission : https://mars.nasa.gov/insight/timeline/prelaunch/landing-site-selection/

NASA. (2018, December 4). RMC Archive 2018. Retrieved from NASA:

https://www.nasa.gov/content/rmc-archive-2018

NASA. (n.d.). About the Moon: In Depth. Retrieved from NASA Science:

https://moon.nasa.gov/about/in-depth/

NASA’s Jet Propulsion Laboratory. (2019, June 12). Earth's Moon. Retrieved from NASA

Science: https://solarsystem.nasa.gov/moons/earths-moon/in-depth/

National Oceanic and Atmospheric Administration. (n.d.). Mars. Retrieved from National Oceanic

and Atmospheric Administration: https://sos.noaa.gov/datasets/mars/

Ormston, T. (2012, August 5). Time Delay Between Mars And Earth. Retrieved from European

Space Agency: http://blogs.esa.int/mex/2012/08/05/time-delay-between-mars-and-earth/

Pettit, D. (2012, May 1). The Tyranny of the Rocket Equation. Retrieved from NASA: Mission

Pages:

https://www.nasa.gov/mission_pages/station/expeditions/expedition30/tryanny.html

Planetary Sciences, Inc. (n.d.). Martian Atmosphere. Retrieved from Planetary Sciences, Inc:

https://planetary-science.org/mars-research/martian-atmosphere/

100

Saidur, R., Rahim, N., Islam, M., & Solangi, K. (2011, June). Renewable and Sustainable Energe

Reviews. Retrieved from Science Direct:

https://www.sciencedirect.com/science/article/abs/pii/S1364032111000669

Sharp, T. (2017, October 31). Atmosphere of the Moon. Retrieved from Space.com:

https://www.space.com/18067-moon-atmosphere.html

Sharp, T. (2017, October 27). What is the Temperature on the Moon? Retrieved from Space.com:

https://www.space.com/18175-moon-temperature.html

Shekhtman, L. (2019, May 2). Martian Dust Could Help Explain Water Loss, Plus Other

Learnings From Global Storm. Retrieved from NASA Mars:

https://www.nasa.gov/feature/goddard/2019/martian-dust-could-help-explain-planet-s-

water-loss-plus-other-learnings-from-recent-global

Shirah, G. (2015, November 5). Solar Wind Strips the Martian Atmosphere. Retrieved from

NASA: Scientific Visualization Studio: https://svs.gsfc.nasa.gov/4370

Space.com. (2011, November 18). NASA Probe Beams Home Best Moon Map Ever. Retrieved

from Space.com: https://www.space.com/13666-moon-map-lunar-reconnaissance-

orbiter.html

Steigerwald, B. (2006, July 31). Electric Dust Storms on Mars. Retrieved from NASA:

https://www.nasa.gov/vision/universe/solarsystem/mars_soil_chem.html

Suescun-Florez, E., Roslyakov, S., Iskander, M., & Baamer, M. (2013, December 19).

Geotechnical Properties of BP-1 Lunar Regolith Simulant. Retrieved from American

Society of Civil Engineers:

https://ascelibrary.org/doi/full/10.1061/%28ASCE%29AS.1943-5525.0000462

101

Suppes, G. J., & Storvick, T. S. (2016). In G. J. Suppes, & T. S. Storvick, Sustainable Power

Technologies and Infrastructure: Energy Sustainability and Prosperity in a Time of

Climate Change (pp. 121-159). Imprint.

Sviatoslavsky, I. N. (1988). Processes and energy costs for mining lunar Helium-3. NASA, Lewis

Research Center, Lunar Helium-3 and Fusion Power.

The Planetary Society. (2018). Chang'e-4: First lander and rover on the Moon's far side. Retrieved

from The Planetary Society: https://www.planetary.org/explore/space-topics/space-

missions/change-4.html

The Planetary Society. (2019). Chandrayaan-2: India's First Lunar Landing. Retrieved from The

Planetary Society: https://www.planetary.org/explore/space-topics/space-

missions/chandrayaan-2.html

UCF Sciences. (n.d.). Planetary Simulant Database: BP-1 Black Point. Retrieved from Center for

Lunar & Asteroid Surface Science: https://sciences.ucf.edu/class/simulant_bp1/

UCF Sciences. (n.d.). Planetary Simulant Database: ES-X Mars Simulants. Retrieved from Center

for Lunar & Asteroid Surface Science: https://sciences.ucf.edu/class/simulant_esx/

Vex Robotics. (n.d.). Clamping Bearing Blocks (6 choices). Retrieved from Vex Robotics: Vex

Pro: https://www.vexrobotics.com/bearingblocks.html

VEX Robotics. (n.d.). VEX Robotics Motor Data - 775pro. Retrieved from VEX Pro Motors:

https://motors.vex.com/vexpro-motors/775pro

Weedmark, D. (2019, 06 26). How to Cost Plan for a Project. Retrieved from Biz Fluent:

https://bizfluent.com/how-8650736-cost-plan-project.html

Williams, D. R. (2018, September 27). Mars Fact Sheet. Retrieved from NASA Space Science

Data Coordinated Archive: https://nssdc.gsfc.nasa.gov/planetary/factsheet/marsfact.html

102

Wong, J. (2011, August 25 ). Predicting the performances of rigid rover wheels on extraterrestrial

surfaces based on test results obtained on earth. Retrieved from California Institute of

Technology: Keck Institute for Space Studies:

https://www.kiss.caltech.edu/papers/xterramechanics/papers/predicting.pdf

Xu, S., Liu, L., Zhu, X., Li, B., Li, Z., Xuan, J., . . . Liu, S. (2012, April 6). China Patent No.

CN201220142992U 20120406. Retrieved from European Patent Office: Patent Search:

https://worldwide.espacenet.com/publicationDetails/biblio?FT=D&date=20121128&DB

=EPODOC&locale=&CC=CN&NR=202560101U

Young, R. J., Williams, M. D., Walker, G. H., Schuster, G. L., & Lee, J. H. (1992). United States

Patent No. US5260639A.

Zou, Y., Xu, L., & Jia, Y. (2018, July). A Tentative Plan of China to Establish a Lunar Research

Station in the Next Ten Years. Retrieved from SAO/NASA Astrophysics Data System:

https://ui.adsabs.harvard.edu/abs/2018cosp...42E3886Z/abstract

103

Appendices

Lunabotics Awards

The Efficient Use of Communications Power Award

Awarded to the team for using the lowest average data utilization bandwidth per icy regolith point

earned in the official runs. Teams must collect the minimum amount of simulated icy regolith to

qualify for this award.

NASA's Solar System Exploration Research Virtual Institute (SSERVI) Regolith Mechanics

Award

Awarded for the best example of a granular materials-related innovation that identified a specific

regolith mechanics problem (e.g. regolith flowing around the grousers, angle of repose too high in

the dump bucket) and improved their design to deal with it. From the NASA Solar System

Exploration Research Virtual Institute (SSERVI’s) Center for Lunar and Asteroid Surface Science

(CLASS).

The Judges Innovation Award

Awarded to the team with the best design based on creative construction, innovative technology

and overall architecture.

The Caterpillar Autonomy Award

The intent of the rules structure for autonomy are to incentivize competitors to pursue autonomy

and develop skills in the area of on-board autonomy – perception, localization, planning, and

machine control. The structure has been established to reward teams for automation of portions of

the operational cycle of the competition. Automation of portions of the cycle allows teams to build

capability leading to full autonomy. It should be noted that historically several teams have

104

leveraged automation to improve their remote-control performance. Excavation automation is a

great example of this approach.

Prizes are awarded to the teams with the first, second, third, fourth, fifth, and sixth most

autonomous points averaged from both mining attempts. Not all point levels require icy regolith

to be deposited. In the event of a tie, the amount of icy regolith (rock/gravel) deposited will be

used to break the tie if possible. If not, the Mining Judges will choose the winner. The fourth, fifth,

and sixth places are new to the Caterpillar Autonomy Award. The intent is to incentivize more

teams in attempting autonomy.

Systems Engineering Leaps & Bounds Award

Awarded to the team that made a significant improvement over the previous years (or consistently

sustained improvement) in their application of systems engineering to the development of their

robot as demonstrated by their systems engineering paper (teams placing in the top 3 are not

eligible for this award; not necessarily awarded every year).

Systems Engineering Paper Award

Slide Presentation and Demonstration Award

Public Outreach Project Award

Robotic Mining Award

The Joe Kosmo Award for Excellence

Awarded to the team that scores the most points in all competition events. Joseph Kosmo graduated

from Pennsylvania State University in 1961 with a Bachelor of Science in aeronautical engineering

and began his career with the NASA Space Task Group in the Crew Systems Division, working

on the Mercury Program spacesuit. During the past 45 years, he has participated in the design,

development, and testing of Mercury, Gemini, Apollo, Skylab, and Space Shuttle spacesuits, as

105

well as numerous advanced technology configuration spacesuits and EVA gloves for future

mission applications.

Kosmo received the American Astronautical Society’s Victor A. Prather Award, the NASA

Exceptional Service Medal, and the Astronaut Silver Snoopy Award. He has pursued the

development of advanced spacesuits, gloves, and ancillary EVA-supporting hardware concepts for

future planetary surface exploration. In 2011, he retired from NASA after a 50-year career in the

space industry. This award honors his service and contributions to America’s space program.

106

Sketches

Figure 54. Sketch of various details regarding external and internal auger components

107

Figure 55. Sketch of potential auger design

108

Figure 56. Sketch of potential drill design with delivery hole at the top

109

Figure 57. Sketch of potential auger mechanism

Figure 58. Sketch of potential auger mechanism being put in the ground, and depositing contents

110

Sinkage Calculations

The green boxes are the inputted numbers found from research or through CAD. The yellow boxes

are constants that most costly resemble the material we will encounter at the competition.

Table 18. Sinkage Calculations for Robot Wheels

Equation 10. Bekker Pressure-Sinkage Equation

Equation 11. Recce Pressure-Sinkage Equation

111

Four Bar Calculations

Figure 59. Four-Bar Matlab calculations

Variable Amount Variable Amount

𝐴𝑥 -0.0009 N 𝐴𝑦 0 N

𝐵𝑥 -0.0009 N 𝐵𝑦 0 N

𝐶𝑥 0.0074 N 𝐶𝑦 -0.0040 N

𝐷𝑥 0.0074 N 𝐷𝑦 -0.0040 N

𝑀𝑑 2.3873 N*mm

Table 19. Four bar static analysis force results

112

Bucket Free Body Diagram Results

Variable Amount

𝐵𝑦 -70N

𝐵𝑥 45N

𝐴𝑦 70N

𝐶𝑥 45N

𝐶𝑦 160N

𝐷𝑦 90N

Table 20. Bucket static analysis force results

Sequence Diagrams

Documents

seseWORCESTER POLYTECHNIC INSTITUTE Computer Science, … · 2020. 5. 18. · NASA Lunabotics 2019-2020 A Major Qualifying Project submitted to the Faculty of WORCESTER POLYTECHNIC