seseworcester polytechnic institute computer science, … · 2020. 5. 18. · nasa lunabotics...
TRANSCRIPT
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
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