UIC Systems Engineering Report-signed

Systems Engineering
Report
NASA Robotic Mining Competition
Engineering Design Team
University of Illinois at Chicago
Compiled by:
Michael Bailey
Edgar Collin
Krystian Gebis
Tim Mueller-Sim
Ammar Subei
Basheer Subei
Faculty Advisor
Miloˇs ˇZefran
Team Members: Michael Bailey, Krystian Gebis, Jon Kopfer, Mateusz Kubak, Tim Mueller-Sim,
Nasif Mahmood, Colin Sheppard, Ismail Siddiqui, Ammar Subei, Basheer Subei and Gerard Ziomek
The Faculty adviser has reviewed this document
prior to its submission.
________________________________________

Contents
1 Introduction 1
2 Pre-Phase A and Phase A 1
2.1 Mission Objective and Design Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Stakeholder Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.3 2014 Failure Mode Analysis and 2015 Robot Objectives . . . . . . . . . . . . . . . . . . . . . 2
2.4 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.5 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.6 Concept of Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.7 Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.8 Project Simulation Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Phase B: Preliminary Design 4
3.1 Interface Assembly (Base Chassis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Preliminary Design Reviews of Interface Assembly . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Locomotion Conﬁguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Simulation Model of Locomotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Preliminary Reviews of Simulation Model of Robot for Autonomy . . . . . . . . . . . . . . . 7
3.6 Wheel Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7 Preliminary Design Review of Wheel Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8 Upper Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.9 Review of Joint Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.10 Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.11 Preliminary Reviews of Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.12 Power System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.13 Communication System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.14 Preliminary Review of Communication System . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.15 Autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.15.1 Sensor Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.15.2 Localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.15.3 Odometry Concept Design Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.15.4 3D Depth data of Immediate Surroundings . . . . . . . . . . . . . . . . . . . . . . . . 12
3.15.5 Path Planning: Motion Trajectories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.16 Interface Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.17 Technical Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.18 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Phase C: Final Design and Fabrication 16
4.1 Established Fabrication Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2 State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Final Design Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Phase D: System Assembly, Integration, Test and Launch 19
5.1 Assembly Review of Bolted Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Testing and Veriﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Project Management 20
6.1 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Peer Review Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3 Financial Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A System Overview 21
B Program Gantt Chart 22

1 Introduction
The NASA Robotic Mining Competition is an event that challenges university students to design and build
a mining robot capable of operating under simulated planetary conditions, such as those that would be
encountered on the surface of the Moon or Mars. The requirements of the competition also provide university
students with the opportunity to engage younger students in the fields of science, technology, engineering,
and mathematics. Throughout the mining portion of the competition, points are awarded for optimizing
parameters such as vehicle mass, overall size, regolith simulant tolerance and projection, and autonomous
operation.
A systems engineering approach is necessary to ensure optimal design, operation, and reliability of the
final mining robot prototype. In essence, it minimizes risk over the lifecycle of the entire project, and ensures
that all likely aspects of the project are considered and integrated into the whole. Fantastic examples of
the robustness of a project developed using systems engineering principles are the NASA rovers Sojourner,
Opportunity, Spirit, and Curiosity. The engineers and scientists who developed these robots undertook the
ultimate test; sending their design on a 140,000,000 mile, two and a half billion dollar journey with no chance
to repair an oversight or fix an afterthought. Their success required a strict systems engineering approach,
which in turn began with accurate system models.
This paper aims to describe the following system engineering processes that the UIC team used to develop
the Surus autonomous mining robot. A well-tested and successful approach is as follows: comprehensively
identify project goals, develop a concept of operations that describes the mining robot’s needs within its
operating environment, develop testable system requirements, document the detailed design of subsystems,
implement the finalized designs, and verify and validate system operations. As discussed in the NASA
Systems Engineering Handbook, systems engineering looks at the “big picture” when technical decisions have
to be made, and ensures the final design is safe and balanced in the face of conflicting constraints [1].
2 Pre-Phase A and Phase A
2.1 Mission Objective and Design Philosophy
The primary objective of the Surus is the collection and deposition of lunar regolith simulant within the
framework of rules and constraints set by the NASA Robotic Mining Competition. Secondary objectives
include the minimization of total robot mass, autonomous operation of control systems, and efficient power
usage, while lesser emphasis was placed on minimizing communications bandwidth. The team’s design
philosophy is to optimize the holistic performance of the system, instead of trying to optimize a specific
technical resource alone. Optimization of these parameters will increase the team’s chances of winning the
prestigious Joe Kosmo Award for Excellence.
2.2 Stakeholder Expectations
The following stakeholders were defined: the University of Illinois at Chicago is a stakeholder because it
provides the primary source of financial budget and facilities. The University’s intended use of the project is
to create technology development in robotic design and provide students with additional avenues for learning
and development. NASA was defined as a stakeholder for creating and hosting the competition. NASA’s
intended use of the project is to develop technology on planetary excavation [2] The team’s faculty advisor is
a stakeholder providing an investment of time to ensure the technical merit of the project. Faculty advisor
intended use is to create technology development in mobile robot configurations and provide students with
additional avenues for learning and technical development. Each of these stakeholders expects a planetary
excavator as a product.
1

2.3 2014 Failure Mode Analysis and 2015 Robot Objectives
Analysis of the previous project was conducted as part of phase F (project closeout) for the 2014 project.
A review of phase F ﬁndings was conducted by all the team members upon return from the competition in
June of 2014. The output from this review was the creation of two documents 2014 Failure Mode Analysis
and 2015 Robot Objectives. These documents (Figure 1) were constructed to identify source and causation
of failures and high level objectives for the 2015 project lifecycle to help guide the next project lifecycle.
Figure 1: 2014 model Hushpuppy, 2014 Failure Mode Analysis and 2015 High-level Objectives
2.4 System Requirements
Baseline system requirements were derived from the NASA Robotics Mining Competition Rulebook [2].
These were documented to ensure the system met the technical requirements of the project. Requirements
were categorized into three sections: mechanical, electrical, and software.
Figure 2: System requirements
2.5 System Overview
Figure 3: System Hierarchy
2

2.6 Concept of Operations
Two preliminary concepts of operations (conops) were developed for Surus. The overall conops were devel-
oped corresponding to competition rules and the intended scope of operation (Figure 4). This concept model
simulates requirements of the overall system operations.
Figure 4: Overall system conops
1. Place the robot into the mining arena
2. Initialize the robot’s power systems for initial system
bootup sequence to establish network connection
3. Initialize internal autonomous system data logging
4. Autonomously localize the robot’s random starting
position by locating beacon
5. Traverse through the mining arena to digging zone
6. Mine a suﬃcient amount of BP-1 regolith
7. Return to starting area and dump the accumulated
BP-1 regolith
8. Repeat steps 1–7 until the round time limit has been
reached
9. Constantly determine state of autonomy
10. In the event that autonomy is determined to be
no longer functional, switch over to manual tele-
operational mode
11. Continuously repeat steps 4–7 until round time limit
has been reached
12. Once the round time limit has been reached, conﬁrm
that all internal robot data logs have been properly
saved
13. Properly shut down the autonomy computers
14. Disengage all power systems and remove robot from
mining arena
3

2.7 Work Breakdown Structure
Figure 5 presents the work breakdown structure used to guide project technical planning and scheduling.
This structure was used to deﬁne the scope of work needed to complete the project, providing an outline for
the entire project.
Figure 5: Work Breakdown Structure for planetary excavator
2.8 Project Simulation Models
To evaluate structural frameworks, FEM models will be created for simulation. These framework simula-
tions will consist of Euler Bernoulli beam elements for structural tubing, and plate elements for paneling.
Applied loads are derived from free body diagrams and model formulations will be reviewed via peer review.
More complex component geometries will be modeled using ﬁnite element simulation from a validated CAD
software package.
The models used to evaluate motor control systems will be done in MATLAB or Simulink. These models
will be used to create the preliminary design of the control system. In this formulation process, dynamics and
control parameters can be simulated and tuned. A holistic simulation of the robot can be done in Gazebo,
which can be used in conjunction with the Robot Operating System (ROS).
The basis for the mechanism used to deposit regolith in the collector bin will be a revolute-planar-revolute
four bar linkage mechanism, which can be analyzed using vector loop closure. Gazebo, the primary simulator
used in conjunction with ROS, is only capable of simulating lower pairs. Mechanisms which feature higher
order pairs which need to be encapsulated in this simulation will be highly penalized in design revisions.
3 Phase B: Preliminary Design
3.1 Interface Assembly (Base Chassis)
The design goal for this sub-assembly was to create a modular design where the interface assembly was
able to provide a central chassis, which is the primary high level interface for the subsystems of the robot.
Additionally, the assembly must ensure structural stability, have a geometry that facilitates the mining
objective of the competition, and provide protection from the harmful regolith for delicate electrical and
computer subsystems on the robot (Figure 6) displays the subsystems which connect to the interface assembly.
4

Figure 6: Subsystems which connect to the interface assembly.
With the specified design constraints, the general geometry of the interface assembly was defined. In
order to facilitate optimal decisions in preliminary design, the doctrine of successive refinement was employed
to create crisp assessments of system functionality [1]. From this geometry initial concept drafts were created
and iterated with the goal of minimizing mass while maintaining structural integrity of the framework. In
order to create a finite element model for the framework, the nodes, locations, element types, and material
properties were defined. The finite element model was constructed using Euler Bernoulli Beam elements
for the structural tubing and plate elements for the panels and base plane. The purpose of this refinement
was to ensure the design met system requirements and to validate that the subsystem fulfilled structural
requirements.
3.2 Preliminary Design Reviews of Interface Assembly
Throughout the design process, technical reviews of the design were performed. The machinists at the UIC
Physics Machine Shop were a receptive and instrumental audience for the project. The primary focuses of
the reviews between the machine shop and the team were manufacturing techniques and ensuring robustness
of the design. A few notable outcomes of these reviews were the use of plugs in structural tubing, in areas
where wear on the tube could reduce component life, and insights into metal bending. A preliminary review
was requested with the student organization governing body on the design of the interface assembly.
3.3 Locomotion Configuration
The locomotion configuration must fulfill the requirements of navigating and performing tasks in an unstruc-
tured environment [3]. The team’s previous model utilized a non-articulated tied mode for the locomotion
configuration. The locomotion system determines the performance of a mobile robot. A high performance
locomotion system will allow a robot to maintain control authority on hazardous terrain. Loss of mobility
is a common failure in the NASA Robotic Mining Competition, so much so that the judges have coined
a term “diagonalization”. Diagonalization describes a failure which occurs when one wheel loses traction
causing another wheel to dig itself into a hole, resulting in a catastrophic loss of mobility. The team was
interested in adopting concepts presented in planetary exploration locomotion studies with the aim of in-
creasing the range of operating conditions of the planetary excavator. In order to determine what locomotion
configuration would be appropriate for the robot, the team developed a trade study (Figure 7).
5

Figure 7: Locomotion configuration decision matrix.
1. Reliability: Evaluated based on technology devel-
opment and published evaluations of configurations,
possible failure modes including ability to effectively
manufacture and assemble the system.
2. Ruggedness: Evaluated based on number of ex-
posed kinematic joints, and resilience to harsh envi-
ronments.
3. Simplicity: Evaluated based on number and type
of kinematic pairs and links,as well as manufactura-
bility.
4. Mass: Evaluated by number of links, and power
transmission components.
5. Performance: Evaluated by documented perfor-
mance of systems from technology development and
published evaluations of configurations.
6. Geometry: Evaluated by analyzing required space
allocation for each configuration.
7. Development: Evaluated based on the quantity of
configuration documentation and the mobile robot
community’s response to work.
Figure 8: Design goals for locomo-
tion system
The MSD (mass spring damper) system was found to have poor
geometry, mass and to be harmful to locomotion performance in this
terrain [4]. The Crab I, II, MER and RCL-E configurations exhibit
strong locomotion characteristics [5, 6, 7]. The MER configuration was
penalized for its use of a differential gear and a higher order pair (see
Section 2.8 ). The tied system scored well overall, but scored poorly in
mass due to having additional power transmission components. The
Crab configurations scored lower than overall RCL-E due to additional
links and kinematic pairs (mass and points of failure). Based on the
design goals for this subsystem (Figure 8) an RCL-E analogous system
was selected.
From this trade study, the basis of the locomotion system
was defined. The kinematics of this system are the link ra-
tios and joint types employed in RCL-E. In order to facilitate good decisions in preliminary de-
sign, the doctrine of successive refinement was employed to create crisp assessment systems (Figure
9). From these iterations, the team defined the structural geometry of the links, defined needed
interfaces, and simplified the system removing walking actuators and explicit steering functionality.
3.4 Simulation Model of Locomotion Base
Link

Transverse
Bogie

Right
Rear

Wheel

Le4
Rear

Wheel

Base
Link

Bo5om
Link

Front

Ver9cal

Link

Middle

Ver9cal

Link

Middle

Wheel

Front

Wheel

Top

Link

Failure
Mode

Analysis

Findings
from

Pre-‐Phase
A

and
Phase
A

Pic
1

Figure 9: Diagram of successive refinement
for locomotion system
The team classified the simulation model for the robot to be
a tangible subsystem, because it forms the primary basis for
integration/testing and design evaluations. In the ROS archi-
tecture, this model is treated as a node allowing for the auton-
omy architecture to be simulated in parallel with the robot’s
physical response. This model creates a platform for testing
different locomotion configurations utilizing the Gazebo physics
engine. The important identified parameters to include in the
simulation were terrain geometry, robot kinematics, and robot
physical properties.
6

Figure 11: Simulation of the non-articulated (left) and articulated (right) rover driving forward
3.5 Preliminary Reviews of Simulation Model
of Robot for Autonomy
Figure 10: Diagram of successive re-
finement for Gazebo Simulation
The goal of these reviews was to evaluate whether the created model
encompassed critical parameters of the robot. A review was conducted
between the team lead, head of software, and faculty advisor to discuss
applicability of kinematic simplifications in the model. The output of
this review was that it was found that an open kinematic chain sim-
plification of the locomotion system would not encapsulate important
parameters of the robot. An additional informal review was conducted
at ROSCon 2014 with Dr. Steve Peters, a software engineer at Open
Source Robotics Foundation. The output of this review was technical
assistance which allowed the team to simulate closed loop kinematic
chains in Gazebo (Figure 10).
Because the tied chassis configuration and the RCL-E configuration
scored closely additional verification was required to formally specify
a locomotion configuration. Figure 11 shows the orientations obtained
during simulations of the two rovers driving forward. In the simula-
tions, the Y axis of the robot points forward while Z points up. This
simulation shows that that the trajectories of the two designs are dramatically different. As can be seen in
the left panel of Figure 11, the trajectories of the rigid chassis are visibly more oscillatory than the trajec-
tories of the articulated chassis (right panel of Figure 11), suggesting that the vibrations due to the terrain
are much better suppressed by the articulated chassis. These findings were used as verification that the
augmented RCL-E chassis met the requirements of the locomotion configuration.
3.6 Wheel Assembly
The constraints imposed on the wheel design were primarily geometric, and had to be contained within
allotted space. Within these initial constraints, parameters were optimized to minimize the overall mass
of the assembly, maximize the available tractive effort, minimize lateral loading experienced during zero-
point turning, and optimize the reliability of the assembly. Using the lessons learned from the successful
implementation of the previous year’s wheel design, the team made efforts to maintain a large wheel diameter
and utilize many grousers. With the inclusion of a new passive differential mobility suspension system
requiring six wheels, the overall diameter of the wheels had to be reduced; this reduction of surface area in
contact with the terrain was counteracted by the increase in the number of wheels.
The overarching wheel geometry was chosen as a result of previous research by D. Apostolopolous,
which indicated that a road-tire geometry results in maximum traction in granular soils [Apostolopolous01].
7

Working within geometric constraints, a rudimentary design was developed that consisted of 3 structural
components: an outer hub which mates to the drive-train, transverse beams upon which the shell of the
wheel is placed, and the inner hub which rigidly connects the transverse beams together. These primary
components would be iteratively altered until all desired parameters are optimized.
3.7 Preliminary Design Review of Wheel Assembly
Figure 12: Wheel hub trade
study
Throughout the design process, technical reviews of the wheel design were
performed. A primary objective of the initial technical reviews was to in-
vestigate the feasibility of incorporating compliance into the hub of the
wheel, so as to decrease shock loading on the rest of the robot frame
resulting from the wheel’s interaction with the terrain. After perform-
ing extensive finite element analysis and a trade study shown in Figure
12, it was determined that a rigid spoke design would be optimal, as
the increased performance of the compliant hub would not overcome the
increased cost and manufacturability.
3.8 Upper Assembly
The role of the upper assembly was to achieve the mining objectives of the system. For this functionality
the upper assembly must collect, store, and deposited regolith. The design goal was to design an excavation
system specifically tailored for a Martian environment. In a low gravity environment normal force created
from weight will be lower additionally with low robot mass (mass is a valuable technical resource). To account
for this the excavation system should use work, rather than pure force to excavate. Satisfy this constraint
the robot’s dig mechanism should collect regolith using continuous excavation. Bucket ladders and bucket
wheels are two continuous excavators. Bucket wheels have been shown to be more robust than bucket ladders
however, to minimize mass the team accepted this trade off and selected a bucket ladder as the excavation
method. The other tradeoff that had to be analyzed in design of upper assembly was use of one or two linear
actuators to raise and lower the upper assembly. Two linear actuators would require a well-tuned feedback
control system, but could reduce the mass of framework by creating for efficient structural geometry. One
linear actuator would require a simple control system but require greater force to raise the system, effect
depositing regolith, and create a cantilever beam structure. With the ability to tune control specifications
the additional control complexity of a two linear actuator set up was deemed acceptable. With mass as a
technical resource carbon fiber composite offered a mass efficient method of designing a container basin.
3.9 Review of Joint Reliability
The goal of this review was to ensure that joints used in the robot, both permanent and non-permanent, were
designed reliably and met technical requirements of connection types. In this review, joints were categorized
by joint types. Welds were identified as the primary permanent joint used in the system. To ensure reliability,
freebody diagrams and models were reviewed such that the joint strength was sufficient for the expected
loading condition. Non-permanent joints were designed and reviewed in accordance to bolted connection
standards. Bolted connections were evaluated by modeling equivalent created spring and safety guidelines.
Figure 13 displays the configuration management of non-permanent connection designs in Phase B. This
review impacted the successive refinement across multiple subsystems of the robot.
3.10 Control System
The design goal of the robot’s control system was to optimize simplicity by evaluating control system per-
formance specifications (stability, response quality and robustness) [8]. To accomplish the functionality of
system requirements, six actuation units were defined. Control structures and alternatives were proposed
8

Figure 13: Management of non permanent connections in preliminary design.
based on the purpose of the actuator. The drive motors power locomotion. To mitigate the risk of “diagonl-
ization” the CAN protocol can be used to ensure that linked wheels are commanded at the same input. The
digging motor powers the upper assembly digging mechanism. While two linear actuators are used to de-
posit collected regolith from the collection basin, the camera linear actuator raises the camera to its deployed
position. For each of these motors, closed loop vs. open loop feedback control were identified as alternative
designs. In order to facilitate good decisions in preliminary design, the doctrine of successive refinement was
employed to create crisp assessments system (Figure 14). Initial concept control configurations were created
by evaluating the functional requirements of each motor.
Figure 14: Diagram of successive refinement for actuator control systems
3.11 Preliminary Reviews of Control System
Control system reviews included mechanical team members who were assigned controls and software members
assigned the design of autonomy. The output of these reviews were decisions based on the type of control
to be used for motors on the robot based on simulation and design goals. For example, it was decided that
the drive motors operate in open loop. This was determined to be the acceptable control system, because
the autonomy architecture acts like a controller in the loop and wheel slippage makes drive motor feedback
an inaccurate method of determining odometry. The dig motor was also designed to operate in open loop.
The control type of each motor and the rationale for the preliminary design decisions based on design goals
is tabulated in Figure 15.
3.12 Power System
The design goal of the power system was to select a DC power supply that would meet the needs of required
electronics and actuators while minimizing mass (high specific energy). Although the robot subsystems had
changed, the 2014 power source (24V 20.8 Ah Lithium-Ion Battery) was considered to be an acceptable power
source for this year’s configuration. This decision reflects on the design objectives (high specific energy).
9

Figure 15: Preliminary design of control systems
3.13 Communication System
Determining what constraints the robot’s system presented, the RS-232 protocol was determined as the
necessary means of communication to the Locomotion subsystem. The Locomotion subsystem is comprised
of five individual motor controllers, which allow different subsystems to interface with the driving and digging
motors.
To safely and automatically switch between different robot operating modes when necessary, a signal
multiplexer (SigMux) design was identified as a subsystem that would meet these needs. The SigMux fulfills
the need to detect failures or miscommunication in the robot’s autonomy system, automatically switching
to a secondary communication pipeline, allowing for manual teleoperation to take place from the command
center.
The SigMux has different operating modes to ensure safety and full control over the robot. The operating
modes are safe mode, manual mode, and autonomous mode. Safe mode, enabled by default on system
power-up, disconnects the robot’s communication with the motor controllers for safety precautions, when it
is desired to either halt the robot or switch from autonomous mode to manual mode (vice versa); safety mode
will also be manually enabled from the command center at the end of each competition round. Autonomous
mode enables the possibility for the robot’s on board autonomy computers to communicate with the motor
controllers over the RS-232 protocol. Manual mode enables for teleoperation commands being sent over
a secondary WiFi module on-board SigMux itself. The SigMux then allows for only the command center
teleoperation commands to be sent to the motor controllers, disregarding any motor commands coming from
the autonomy subsystem.
The robot’s different modes can be chosen from a higher level user interface that is controlled from the
command center.
As a failsafe system, the SigMux has also been designed to contain a watchdog system, which monitors
whether a connection between the SigMux’s WiFi module and the wireless router is established. In the event
that no connection is present for a certain amount of time, the SigMux then quickly power-cycles to try and
restart the connection to the router. This however, does not affect the state of the on board multiplexer, as
it is designed to by default to allow the autonomy system to communicate with the Locomotion subsystem.
The flow diagram for the communication system is shown in Figure 16.
3.14 Preliminary Review of Communication System
The Signal Multiplexer PCB design was sent to Chicago EDT’s email “list-serv”, which had multiple alumni
subscribed, for review purposes. The first revision made multiple changes that include spacing out the traces
and via holes, repositioning multiple connectors and ICs, and realigning some components for optimization.
The second revision added a ground plane on the bottom layer of the SigMux circuit board, which sub-
stantially decreased the amount of traces on the board and made more room for connector and via hole
clearances. The second revision also eliminated the use of two unnecessary logic level shifters, thus creating
10

Figure 16: Communication flow diagram
more room and decreasing the board size. The final revision introduced the use of test points for easier in-
spection of critical nodes, a new, smaller, and more efficient DC/DC converter, and furthermore decreasing
the dimensions of the board.
3.15 Autonomy
3.15.1 Sensor Data
On an extra-terrestrial mining rover, the single-most essential task for autonomy is to be able to accurately
and reliably locate itself and its surroundings in order to navigate through unknown environments. Given
filtered odometry data, the robot can localize itself relative to the mapped environment. Acquiring and
fusing data from the environment around the robot is integral for the purposes of building this map and
localizing itself within it. Without it, the robot will be unable to plan its actions, as it lacks sufficient
information of its surroundings. The team has determined that the system requirements for sensor data are:
• Localization
• 3D depth data of immediate surroundings
3.15.2 Localization
There are various ways and sensor modalities that can be used to determine the odometry and location of the
robot, ranging from simple methods like single-dimensional laser range-finders to 3D LIDAR scanners. The
design goal of localization was to optimize data usage and create an accurate odometry estimate. The team
approached this problem by identifying the crucial pieces of data required to achieve the goal of localization
calculation. In order to create a robust system, the team decided to collect multiple sources of localization
and integrate them into a single filtered odometry output. This data will then be used to interface with the
autonomy system, specifically with the path planning and navigational subsystems. The team identified the
following various feasible methods to obtain localization data:
11

• Wheel Encoders
• RGB-Depth sensors (Kinect)
• 2D LIDAR
• 3D LIDAR
• Inertial Measurement Unit (IMU)
• RF Beacon
• Stereoscopic Camera Visual Odometry
• Visual Marker Beacon
• Optical-Laser Beacon
3.15.3 Odometry Concept Design Review
In a chaotic particulate terrain environment, wheel slippage makes wheel encoder data unreliable as an
odometry input. The 3D LIDAR sensors were prohibitively expensive and would produce too much data
where more then half of it would not be used. The team determined that a 2D LIDAR would not be used
since the competition requirements specify that a robot cannot use the arena walls for means of localiza-
tion. This eliminates discrepancy as to whether or not the team is meeting the competition requirements.
The stereoscopic visual odometry algorithms required excessive amounts of processing power to achieve real
time operation. Finally, RF and Optical-Laser beacon methods were ruled out as the team lacked sufficient
experience in implementing these methods.
After a review of the available methods of odometry, the team decided that the primary odometry
source will be obtained using visual markers placed above the dumping bin, which act as a beacon, yielding
relative position and orientation to the bin (represented as a transform from the camera frame to the marker
frame). The team determined that the secondary odometry sources would be an IMU as well as a 3D visual
odometry algorithm using data from the Kinect RGB-D sensor, disregarding all 3D data points above the
highest possible terrain threshold set by the competition rules (30cm) to avoid discrepancy of using the arena
walls for means of localization.
3.15.4 3D Depth data of Immediate Surroundings
Besides odometry, a secondary purpose of the sensor data that we collect from the terrain is for obstacle
detection/avoidance. When a large enough obstacle (such as a rock or boulder) is found, it needs to be
marked as an obstacle and placed correctly in the map of surroundings that we build.
3.15.5 Path Planning: Motion Trajectories
The next objective for the autonomy system is to identify a heuristically optimal plan to reach the goal.
This involves calculating a path to follow on the ground to and from digging/dumping sites. The team
determined that calculating motion trajectories across our map in three dimensions would require excessive
amounts of processing power and development time to achieve. Therefore, a more simplified approach was
deemed necessary, specifically one that reduces the amount of unnecessary data that the robot gathers from
the environment. An appropriate and elegant solution is to assume a two-dimensional motion trajectory
for our navigation purposes. The three-dimensional mapped environment will simply be projected onto a
two-dimensional plane, and the obstacles can be placed on a two-dimensional occupancy grid or map, with
each cell in the map representing the cost of traversing over that region. Thus, a costmap [9] is built from
the surroundings and is used as an input into the algorithm to plan motion trajectories.
The second type of input into the motion planning algorithm is the possible motions that the rover can
perform. These are called the motion primitives, and they represent the most basic discrete motion param-
eters that the rover can perform and is physically constrained by. The motion primitives we calculated are
shown in Figure 17.
Once the motion planning algorithm receives these two inputs, it can determine an optimal motion
trajectory from the current map position to the goal, given the motion primitive constraints and the cost of
traversing certain areas of the map. However, there are many ways to design an algorithm that calculates
12

Figure 17: Motion Primitives
such a motion trajectory. The team identiﬁed two broad categories of these, namely those algorithms that
determine the most optimal trajectory after an exhaustive search, and those algorithms that heuristically
determine an optimal enough trajectory given an error bound. Given the processing power constraints, the
team decided to use heuristic algorithms to determine the motion trajectory.
3.16 Interface Management
Figure 18: The articulated rover
with local coordinate frames for
each link
The interface assembly frame was deﬁned as the central reference coor-
dinate frame (base frame). Figure 18 displays the coordinate systems of
the rigid bodies of the robot. Camera feedback is collected relative to the
camera frame which is then transformed to the baseframe. The Kinect
frame is transformed by a constant translational transform. The monocu-
lar camera frame is transformed by a rotational (servo position feedback)
and translation transform (mounting location on robot).
The upper assembly is connected to the interface assembly by a rear
axle. The actuators which raise and lower the system are connected to the
upper assembly and interface assembly by respective axles. The locomo-
tion system connected to the interface assembly by axle originating from
the interface frame. Electrical components are mounted on base plane
or side panels of the interface assembly, secured with fasteners. Electri-
cal enclosures protect components from regolith, and are mounted on the
base plane or side panels.
13

Figure 19: Exploded view and assembly view of preliminary design
Figure 19 displays an exploded assembly to visualize subsystem interfaces of the robot. Control param-
eters are initialized in Roboteq Roborun, then uploaded to motor controllers. The CAN circuit connects
motor controllers using an embedded circuit board; the circuit will be embedded to increase reliability and
organization. Sensor feedback for autonomy is collected, transformed, and sent to the the Kalman filter
which weighs and combines sensor data. This filtered data is then used in autonomy algorithms.
3.17 Technical Resource Management
Figure 20: Phase B estimated mass budget breakdown
In Phase A, initial high-level technical resource estimates were created. Upon the completion of pre-
liminary designs, technical resources were reevaluated. Two technical resources were identified as primary
limiting factors for the mission: power consumption and mass of the robot. Figure 20 displays mass break-
down, showing subassembly usage of mass budget. The upper chart displays usage relative to the competition
limit, while the lower chart displays subassembly usage relative to the team’s mass objective.
14

Energy was another critical technical resource for the mission, and our estimated energy budget break-
down is shown in Figure 21.
Figure 21: Phase B estimated energy budget breakdown
Other identified technical resources were bandwidth and processing power. Conserving bandwidth as a
resource, however, had a lesser priority, while processing power held a higher priority, which was measured
by the number of effective CPU cores available on all the embedded computer systems.
With the technical resource budget reviewed based off preliminary design, this completed the technical
resource management for Phase B.
3.18 Risk Management
Planetary excavation is a high risk mission, involving such hazards which could jeopardize the effectiveness
of a mission. In order to effectively reduce risks and achieve the project goal, the project utilized risk
management concepts. Based on experience, peer reviews, and design evaluation, the following risks were
identified from preliminary designs [10]. These risks were identified to be tracked and evaluated through
fabrication, testing, and mission deployment. The risk matrix pictured in Figure 22 displays the identified
risks and their risk level.
Breakdown of Team Communications: This failure is of high likeliness and frequency. It would
not result in mission failure, but it could however result in delays in program progress. Assistance from the
faculty advisor, regular team meetings, and an emphasis on communication were steps taken as contingency
options/procedures to mitigate this risk.
Regolith Coating Mechanical Interfaces: This failure is of high likeliness due to the environment
conditions. It would not result in mission failure, however it may lead to reduced performance of moving
parts.
Autonomy Fails to Complete Objectives: This failure is of moderate likeliness due to the intrinsic
challenges of performing an automated task in a chaotic environment. The consequences of this failure would
be failure to complete autonomous excavation requiring manual control of the robot. Although this failure
would not result in complete mission failure it would greatly reduce the operational capabilities of the robot.
Incomplete Models: This failure is of high likeliness due to the chaotic environment conditions. Models
for terramechanics and locomotion on deformable terrain are often empirical rather than deterministic [11,
12, 13, 14, 3]. The simulated robot model used in autonomy simulation used an environment consisting of
rigid bodies. The robot’s performance is dependent on the degree to which assumptions made in analysis
encapsulate important parameters of the real system and environment. The contingency for this risk is to
constantly reevaluated the models used and adjust them to more accurately represent the system.
15

Figure 22: Risk matrix for planetary excavator
Failure of Feedback System: This failure is of moderate likeliness due to variation in system dynamics.
This failure could lead to reduction in robot functionality. To reduce this risk, an emphasis was made on
robust design of physical systems and control structures. As a contingency plan, the operator will stop
autonomous operations to troubleshoot the issue with a human in the loop.
Unexpected Loading Conditions: This failure is of moderate likeliness. This risk is innate when
working in a chaotic environment. This condition, if not properly accounted for, could lead to partial or
complete failure of speciﬁc subsystems on the robot. The proposed contingency plan for this risk was to
include current limiters in the control design to guard against actuator failure.
Regolith Failure: This failure is of moderate likeliness and of serious consequence. Excessive dust
production could lead to sensor failure, regolith may embed itself in mechanical joints to the degree that
would cause functional failure [15]. It can also be damaging to electrical components of the robot. To
mitigate this risk, mechanical designs should be robust, electronics should be appropriately sealed, and
autonomy should have appropriate redundancies. As a contingency, the autonomy system makes decisions
from multiple feedback units to guard against one failing.
Improper Assembly of Machine: This failure is of low likeliness. The consequence of this failure
could be mission failure. By following strict assembly procedures, the probability of this failure can be
reduced. If improper assembly is noticed in testing, the contingency plan is to identify origin of improper
assembly, document the failure, and adjust the assembly procedure.
Unstable Autonomy System: The likeliness of this failure is low, however the consequences are grave.
If the autonomy system becomes unstable, it may become a hazard to nearby observers. As a contingency
plan the robot features an emergency stop. Also, an operator may interject and begin to teleoperate the
robot.
4 Phase C: Final Design and Fabrication
4.1 Established Fabrication Procedure
In order to mitigate risk and ensure component reliability, the following fabrication procedure was imple-
mented. In fabrication designs analysis of tradeoﬀs had to be considered. Will the part be manufactured
in-house, outsourced, or utilize additional University facilities? If the component could be reliably manu-
factured using common subtractive manufacturing techniques (such as milling, shearing and cutting) or low
force metal bending, then it would be manufactured in-house. If the component could not be manufactured
16

in house but could be manufactured using local University resources (such as 3d printing, metal bending,
tube bending and welding), then that would be the primary option. After both these options are exhausted,
then the fabrication would be outsourced.
Figure 23: Fabrication procedural hierarchy
Figure 24: Established tolerances for
structural and mechanical components
After each part was fabricated, it was evaluated based
on component functional requirement, and dimensional accu-
racy. Figure 23 shows the procedural approach for fabrica-
tion of components. If tooling to fabricate a part was not
available, but required machinery and the tool could be fab-
ricated using well-documented procedure, then the appropriate
tooling would be designed and fabricated. A standard for tol-
erances for components was deﬁned in order to create relia-
bility, consistency, and create interfaces for the robot. Fig-
ure 24
4.2 Software
4.2.1 Integration
Given the complexity of the proposed autonomy system, the software team realized that there was a need
to develop each subsystem and test it independently. There was also the issue of interfacing the diﬀerent
subsystems, and ensuring that the data structures and types between them are compatible. Therefore, the
design objectives as a whole were to minimize:
• Development time
• Intermodular dependence
• Interface and integration problems
4.2.2 State Machine
The purpose of the state machine is to determine what action the robot should perform, or what location to
travel to in the mining arena (Figure 27). The actions that the robot may perform are listed as the following:
• Localizing the robot by rotating the servo camera until we lock onto the ArUco marker. This will be
performed on the start of the run as well as if the robot loses its sense of position (Figure 28).
• Manually correct position and orientation of robot in odometric coordinate frame relative to the origin
of the arena map coordinate frame
17

Figure 25: Software final architecture operations flow diagram.
• Drive to mining zone
• Lower the Upper assembly digging mechanism into digging position
• Spin the digging motors
• Stop spinning the digging motors
• Lift the Upper assembly into driving position
• Drive to the dumping zone
• Lift the Upper assembly for dumping
Figure 26: N2
autonomy diagram
Since we are given distance parameters as to how far away a
digging zone may be from the dumping bin, we can set pre-defined
goals for where we want our robot to travel and dig regolith.
The state machine is then designed to determine which dig site
location to go to, taking into account the current state/action the robot is in/performing. Observing the state
machine’s decision diagram below, the initial starting action is set to determine the position and orientation
of the robot in one of the two starting areas at the beginning of the mining round.
Figure 27: State Machine Flow Diagram
18

Figure 28: Servo
sweeping-motion of
camera
Taking into consideration the random placement and orientation of the
robot, the initial localization is comprised of two simultaneous steps, which
allow us to know our current starting position relative to a beacon hang-
ing above the dumping bin. The first step consists of a 180 degree servo-
sweeping motion, where 0 degrees is facing directly behind the robot. This al-
lows for a mounted camera to try and lock onto one of the beacon’s mark-
ers (also known as ArUco generated codes), and give the robot information as
to how far away from the beacon it is, as well as what orientation it is fac-
ing.
In the event that the camera has locked onto one of the beacon’s markers, the
state machine will then change its state to traverse towards the mining zone. There
is, however, an expected scenario where the sweeping motion may not allow the
camera to find the beacon; if the front of the robot is oriented towards the dumping
bin, pointing the camera directly away from the beacon, the camera’s field of view and servo’s rotation limits
become an evident constraint. To overcome this obstacle, the state machine is notified by the servo-sweeping
process that the beacon could not be found and a position could not be obtained. A 180 degree zero radius
turn is then performed, to allow for the camera to observe its environment from a different viewpoint. This
action is then repeated, until the robot can locate the ArUco markers.
Obtaining the location of the ArUco markers, allows the state machine to continue through its action
iteration cycle; keeping track of where we are with respect to the marker then allows the robot to traverse
to the mining area. Having already pre-set mining goal points with respect to the ArUco markers, the robot
then approaches first goal point and begins to dig. The state machines “dig” action consists of broadcasting
a message to the actuators to lower the upper assembly digging mechanism into digging position. Once an
echoing message stating that the actuators are in place is received back by the state machine, a “creep-and-
dip” action is then performed by broadcasting a “spin dig motor” message to the motor controllers, and
lowering a max linear and angular velocity parameter, which will then be accessed by the local path planner.
4.3 Final Design Review
The purpose of this review was to verify that fabricated components and final designs met the system
requirements, as well as to document and compare them as built and as designed. Present at this review
were the core members of the mechanical, electrical, and software team.
5 Phase D: System Assembly, Integration, Test and Launch
5.1 Assembly Review of Bolted Connections
Although bolted connections are common, the typical behavior of a bolted connection is quite compli-
cated [16]. Improper assembly of the machine is a risk that must be managed (Figure 22). The following
procedure outlines the procedure for assembly of bolted connections used by the team: perform visual in-
spection of clearance hole and threaded hole. Tension bolt to meet designed preload, to achieve appropriate
factors of safety by applying appropriate torque to bolt head. Visually inspect joint, such that at least two
additional threads exist after the nut. Continue evaluation during testing phase of program.
With the created simulation model, the autonomy functionality was tested from phase B. In this sim-
ulation, the motion primitives were tested and verified to be capable of functionally navigating in both
forwards and reverse. Additionally, autonomous navigation was continually tested using this simulation. In
this on-going phase, the team aims to continue autonomy testing.
5.2 Testing and Verification
19

Figure 29: Current robot in test
arena
In the test arena, (Fig. 29) physical testing of the kinematic functionality
of the locomotion configuration was validated and compared favorably to
the simulated behavior. Wheel functionality was visually inspected and
qualitatively validated to meet system requirements. The actuators that
raise and lower the basin are undergoing ongoing testing to tune feedback
control across a range of process dynamic variations (varying loads). After
the locomotion system and actuators are validated, the team will begin
testing on dig mechanism functionality.
6 Project Management
6.1 Schedule
The project schedule for EDT RMC was done internally and broken up
into three categories.
Long-term schedule: dates and benchmarks, to which the team could gauge the progress of the project
in terms of NASA’s schedule (Figure 32).
Short term work schedules: assigned and adjusted at the end of each weekly meeting.
Software sprints: Small meetups where team focuses on a specific task or objective.
In weekly meetings at the EDT shop progress on these goals was discussed, sub-projects were assigned,
and old schedules were reevaluated. Weekly emails laying out project progress, summary of the meeting,
and new assignments acted as documentation for short-term schedules.
6.2 Peer Review Structure
The philosophy for peer reviews was derived from NPR 7120.5, NASA Space Flight Program and Project
Management Handbook. One anecdote from the document which the team latched onto is:
“Peer Reviews that are really small and really informal are the most productive. There are no RFAs
at Peer Reviews. Results are captured in notes. There is no confrontational aspect to the Peer Review
process.” [17]
Discussions, reviews of designs, and inspections were done at the weekly team meetings and over the EDT
email list-serv. This allowed for design reviews to be done continually throughout the project, facilitating
effective communication and coordination. Inspections were categorized into the following types: system
requirements, system design, subsystem design, control requirements, control design, model requirements,
software requirements, and software design.
6.3 Financial Assessment
Figure 30: 2015 Expenditures
The UIC team is fortunate in that the UIC College of Engi-
neering provides the bulk of the required financial support for
the year. The remaining balance required to field a mining
robot is filled through the generous donations (both monetary
and material) from sponsors such as the Sick Group, Caterpillar
Inc., Ability Engineering Technology Inc., and NASA provided
grants.
As seen in Figure 30, a balance of $1,944.56 remains as of the
submission of this report. With a month left before the compe-
tition, there may be several minor draws from the account due
to unforeseen purchases, but in all the initial budget estimate
for Surus closely matches the required expenditures.
20

A System Overview
Figure 31: System Diagram
21

B Program Gantt Chart
ID Task Name Duration Start Finish Predecessors Successors
Text2: No Value 5 days Mon 5/25/15 Fri 5/29/15
Text1: Milestone 5 days Mon 5/25/15 Fri 5/29/15
1 NASA Robotic Mining Competition 5 days Mon 5/25/15 Fri 5/29/15 2,3FS-30 days,4FS-30 days,5FS-15 days
Text2: Arena 55 days Wed 7/23/14 Tue 10/7/14
Text3: Structure 55 days Wed 7/23/14 Tue 10/7/14
Text1: Test and Refine 55 days Wed 7/23/14 Tue 10/7/14
8 Allocate space for arena for autonomy testing 10 days Wed 7/23/14 Tue 8/5/14 7
7 Design arena for autonomy testing 15 days Wed 8/6/14 Tue 8/26/14 8 10
10 Obtain materials for arena 15 days Wed 8/27/14 Tue 9/16/14 7 6
6 Build arena for autonomy testing 15 days Wed 9/17/14 Tue 10/7/14 10 5FF
Text2: Complete 20 days Wed 11/5/14 Tue 12/2/14
Text3: No Value 20 days Wed 11/5/14 Tue 12/2/14
Text1: Test and Refine 20 days Wed 11/5/14 Tue 12/2/14
5 Verify autonomous functionality 20 days Wed 11/5/14 Tue 12/2/14 6FF,99FF 1FS-15 days
99 Verify robot functionality 20 days Wed 11/5/14 Tue 12/2/14 96,97,98 5FF
Text2: Electronics 100 days Wed 7/23/14 Tue 12/9/14
Text3: Communications 85 days Wed 7/23/14 Tue 11/18/14
Text1: Design 50 days Wed 7/23/14 Tue 9/30/14
82 Design communications system, spec hardware 30 days Wed 7/23/14 Tue 9/2/14 83
83 Review communications and hardware design 10 days Wed 9/3/14 Tue 9/16/14 82 84
84 Submit parts list for communication equipment and 10 days Wed 9/17/14 Tue 9/30/14 83 46,40
Text1: Manufacture 35 days Wed 10/1/14 Tue 11/18/14
40 Procure communications mounting material 15 days Wed 10/1/14 Tue 10/21/14 84 42
46 Procure communications equipment 15 days Wed 10/1/14 Tue 10/21/14 84 47
47 Assemble communications equipment 10 days Wed 10/22/14 Tue 11/4/14 46 42
42 Manufacture communications mount 10 days Wed 11/5/14 Tue 11/18/14 40,47
Text3: Electronics 5 days Wed 10/29/14 Tue 11/4/14
Text1: Assemble 5 days Wed 10/29/14 Tue 11/4/14
98 Assemble electronics components 5 days Wed 10/29/14 Tue 11/4/14 97FF,96FF 99
Text3: Motor Controllers 40 days Wed 9/10/14 Tue 11/4/14
85 Determine proper specs for motor controllers 10 days Wed 9/10/14 Tue 9/23/14 65,93,69 86
86 Review motor controller choice 5 days Wed 9/24/14 Tue 9/30/14 85 87
87 Submit parts list for motor controller 5 days Wed 10/1/14 Tue 10/7/14 86 49,44
44 Procure motor controller mounting material 15 days Wed 10/8/14 Tue 10/28/14 87 45
49 Procure motor controllers 15 days Wed 10/8/14 Tue 10/28/14 87 45
45 Manufacture motor controller mounts 5 days Wed 10/29/14 Tue 11/4/14 44,49
Text3: Sensors 100 days Wed 7/23/14 Tue 12/9/14
88 Determine proper specs for sensors 30 days Wed 7/23/14 Tue 9/2/14 89
89 Review sensor choices 10 days Wed 9/3/14 Tue 9/16/14 88 90
90 Submit parts list for sensors 10 days Wed 9/17/14 Tue 9/30/14 89 51,41
41 Procure sensor mounting material 15 days Wed 10/1/14 Tue 10/21/14 90 43
51 Procure sensors 40 days Wed 10/1/14 Tue 11/25/14 90 43
43 Manufacture sensor mounts 10 days Wed 11/26/14 Tue 12/9/14 41,51
Text2: Equipment 5 days Mon 5/18/15 Fri 5/22/15
Text1: Prep for competition 5 days Mon 5/18/15 Fri 5/22/15
2 Prep robot and tooling for transport to competition 5 days Mon 5/18/15 Fri 5/22/15 1
Text2: House Rental 148 days Wed 7/23/14 Fri 2/13/15
Text3: No Value 148 days Wed 7/23/14 Fri 2/13/15
Text1: Prep for competition 148 days Wed 7/23/14 Fri 2/13/15
26 Scout possible house locations, verify budget 20 days Wed 7/23/14 Tue 8/19/14 4
4 Rent house for 8 people for 7 days 10 days Mon 2/2/15 Fri 2/13/15 26 1FS-30 days
Text2: Lower Assembly 70 days Wed 7/23/14 Tue 10/28/14
Text3: Drivetrain 70 days Wed 7/23/14 Tue 10/28/14
67 Design drivetrain 20 days Wed 7/23/14 Tue 8/19/14 68
68 Review drivetrain design 10 days Wed 8/20/14 Tue 9/2/14 67 69
69 Submit parts list for drivetrain 5 days Wed 9/3/14 Tue 9/9/14 68 9,85
9 Procure drivetrain materials 15 days Wed 9/10/14 Tue 9/30/14 69 15
15 Manufacture drivetrain components 20 days Wed 10/1/14 Tue 10/28/14 9 97FF
Text3: Frame 70 days Wed 7/23/14 Tue 10/28/14
70 Design lower assembly frame 20 days Wed 7/23/14 Tue 8/19/14 71
71 Review lower assembly frame design 10 days Wed 8/20/14 Tue 9/2/14 70 72
72 Submit parts list for lower assembly frame 5 days Wed 9/3/14 Tue 9/9/14 71 13
13 Procure frame materials 15 days Wed 9/10/14 Tue 9/30/14 72 17
17 Manufacture frame 20 days Wed 10/1/14 Tue 10/28/14 13 97FF
Text3: Linkage 70 days Wed 7/23/14 Tue 10/28/14
73 Design linkage 20 days Wed 7/23/14 Tue 8/19/14 74
74 Review linkage design 10 days Wed 8/20/14 Tue 9/2/14 73 75
75 Submit parts list for linkage design 5 days Wed 9/3/14 Tue 9/9/14 74 12
12 Procure linkage materials 15 days Wed 9/10/14 Tue 9/30/14 75 19
19 Manufacture linkage 20 days Wed 10/1/14 Tue 10/28/14 12 97FF
Text3: Lower Assembly 5 days Wed 10/22/14 Tue 10/28/14
97 Assemble lower assembly 5 days Wed 10/22/14 Tue 10/28/14 15FF,17FF,19FF,21FF,23FF 98FF,99
Text3: Wheel 70 days Wed 7/23/14 Tue 10/28/14
76 Design wheel 20 days Wed 7/23/14 Tue 8/19/14 77
77 Review wheel 10 days Wed 8/20/14 Tue 9/2/14 76 78
78 Submit parts list for wheel 5 days Wed 9/3/14 Tue 9/9/14 77 11
11 Procure wheel materials 15 days Wed 9/10/14 Tue 9/30/14 78 21
21 Manufacture wheels 20 days Wed 10/1/14 Tue 10/28/14 11 97FF
Text3: Wiring 43 days Wed 7/23/14 Fri 9/19/14
79 Create wiring layout 20 days Wed 7/23/14 Tue 8/19/14 80
80 Review wiring layout 10 days Wed 8/20/14 Tue 9/2/14 79 81
81 Submit parts list required for wiring 5 days Wed 9/3/14 Tue 9/9/14 80 14
Text1: Manufacture 8 days Wed 9/10/14 Fri 9/19/14
14 Procure wiring materials 5 days Wed 9/10/14 Tue 9/16/14 81 23
23 Run wiring 3 days Wed 9/17/14 Fri 9/19/14 14 97FF
Text2: Transportation rental 148 days Wed 7/23/14 Fri 2/13/15
Text3: No Value 148 days Wed 7/23/14 Fri 2/13/15
Text1: Prep for competition 148 days Wed 7/23/14 Fri 2/13/15
29 Scout possible vehicle configurations, verify budge 20 days Wed 7/23/14 Tue 8/19/14 3
3 Rent vehicle to transport people and equipment fo 10 days Mon 2/2/15 Fri 2/13/15 29 1FS-30 days
Text2: Upper Assembly 75 days Wed 7/23/14 Tue 11/4/14
Text3: Actuators 65 days Wed 7/23/14 Tue 10/21/14
91 Design actuator and framework 20 days Wed 7/23/14 Tue 8/19/14 92
92 Review actuator framework 10 days Wed 8/20/14 Tue 9/2/14 91 93
93 Submit parts list for actuator 5 days Wed 9/3/14 Tue 9/9/14 92 94,85
94 Procure actuator and framework materials 15 days Wed 9/10/14 Tue 9/30/14 93 95
95 Manufacture actuator framework 15 days Wed 10/1/14 Tue 10/21/14 94 96FF
Text3: Bin 70 days Wed 7/23/14 Tue 10/28/14
52 Design bin 20 days Wed 7/23/14 Tue 8/19/14 53
53 Review bin 10 days Wed 8/20/14 Tue 9/2/14 52 62
62 Submit parts list for bin 5 days Wed 9/3/14 Tue 9/9/14 53 32
32 Procure bin material 15 days Wed 9/10/14 Tue 9/30/14 62 33
33 Manufacture bin 20 days Wed 10/1/14 Tue 10/28/14 32 96FF
Text3: Buckets 75 days Wed 7/23/14 Tue 11/4/14
54 Design buckets 20 days Wed 7/23/14 Tue 8/19/14 55
55 Review buckets 10 days Wed 8/20/14 Tue 9/2/14 54 63
63 Submit parts list for buckets 5 days Wed 9/3/14 Tue 9/9/14 55 38
38 Procure bucket material 20 days Wed 9/10/14 Tue 10/7/14 63 39
39 Manufacture bucket 20 days Wed 10/8/14 Tue 11/4/14 38 96FF
Text3: Dig Belt & Pulleys 60 days Wed 7/23/14 Tue 10/14/14
56 Design belt and pulley system 20 days Wed 7/23/14 Tue 8/19/14 57
57 Review belt and pulley system 10 days Wed 8/20/14 Tue 9/2/14 56 64
64 Submit parts list for dig belt & pulleys 5 days Wed 9/3/14 Tue 9/9/14 57 34
34 Procure belt and pulleys 20 days Wed 9/10/14 Tue 10/7/14 64 35
35 Assemble belt 5 days Wed 10/8/14 Tue 10/14/14 34 96FF
Text3: Dig Drivetrain 75 days Wed 7/23/14 Tue 11/4/14
58 Design dig drivetrain 20 days Wed 7/23/14 Tue 8/19/14 59
59 Review dig drivetrain 10 days Wed 8/20/14 Tue 9/2/14 58 65
65 Submit parts list for dig drivetrain 5 days Wed 9/3/14 Tue 9/9/14 59 36,85
36 Procure drivetrain materials 25 days Wed 9/10/14 Tue 10/14/14 65 37
37 Manufacture dig drivetrain components 15 days Wed 10/15/14 Tue 11/4/14 36 96FF
Text3: Frame 75 days Wed 7/23/14 Tue 11/4/14
60 Design upper assembly frame 20 days Wed 7/23/14 Tue 8/19/14 61
61 Review upper assembly frame 10 days Wed 8/20/14 Tue 9/2/14 60 66
66 Submit parts list for upper assembly frame 5 days Wed 9/3/14 Tue 9/9/14 61 30
30 Procure frame material 15 days Wed 9/10/14 Tue 9/30/14 66 31
31 Manufacture frame 25 days Wed 10/1/14 Tue 11/4/14 30
Text3: Upper Assembly 5 days Wed 10/29/14 Tue 11/4/14
96 Assemble upper assembly 5 days Wed 10/29/14 Tue 11/4/14 95FF,33FF,39FF,35FF,37FF 98FF,99
Figure 32: 2014 Project Schedule
22

References
[1] R. Shishko and R. Aster, “Nasa systems engineering handbook,” NASA Special Publication, vol. 6105,
1995.
[2] Robotic Mining Competition NASA.
http://www.nasa.gov/offices/education/centers/kennedy/technology/nasarmc.html.
[3] D. Apostolopoulos, “Analytic Configuration of Wheeled Robotic Locomotion,” Robotics Institute,
CMU, Tech. Rep., Apr. 2001. [Online]. Available: http://repository.cmu.edu/robotics/29
[4] F. Barlas, “Design of a mars rover suspension mechanism,” Ph.D. dissertation, Izmir Institute of
Technology, 2004.
[5] V. Kucherenko, A. Bogatchev, and M. Van Winnendael, “Chassis concepts for the ExoMars rover,” in
Proceedings of the 8th ESA Workshop on Advanced Space Technologies for Robotics and Automation,
Noordwijk, The Netherlands, 2004. [Online]. Available:
http://robotics.estec.esa.int/ASTRA/Astra2004/Papers/astra2004 D-05.pdf
[6] A. Seeni, B. Schafer, B. Rebele, and N. Tolyarenko, “Robot mobility concepts for extraterrestrial
surface exploration,” in Aerospace Conference, 2008 IEEE. IEEE, 2008, pp. 1–14. [Online]. Available:
http://ieeexplore.ieee.org/xpls/abs all.jsp?arnumber=4526237
[7] C. G. Y. Lee, J. Dalcolmo, S. Klinkner, L. Richter, G. Terrien, A. Krebs, R. Y. Siegwart, L. Waugh,
C. Draper, R. Y. Siegwart, and others, Design and manufacture of a full size breadboard exomars rover
chassis. Citeseer, 2006. [Online]. Available:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.149.8434&rep=rep1&type=pdf
[8] S. Cetinkunt, Mechatronics with Experiments. John Wiley & Sons, 2015.
[9] “costmap 2d - ROS Wiki,” http://wiki.ros.org/costmap 2d.
[10] R. W. Malone Jr and K. Moses, “Development of risk assessment matrix for nasa engineering and
safety center,” 2004.
[11] S. J. Moreland, K. Skonieczny, D. Wettergreen, C. Creager, and V. Asnani, “Soil motion analysis
system for examining wheel-soil shearing,” 2011.
[12] H. Nakashima, H. Fujii, A. Oida, M. Momozu, Y. Kawase, H. Kanamori, S. Aoki, and T. Yokoyama,
“Parametric analysis of lugged wheel performance for a lunar microrover by means of dem,” Journal
of Terramechanics, vol. 44, no. 2, pp. 153–162, 2007.
[13] S. Hutangkabodee, Y. Zweiri, L. Seneviratne, and K. Althoefer, “Soil parameter identification and
driving force prediction for wheel-terrain interaction,” International Journal of Advanced Robotic
Systems, vol. 5, no. 4, pp. 425–432, 2008.
[14] A. Wilkinson and A. DeGennaro, “Digging and pushing lunar regolith: Classical soil mechanics and
the forces needed for excavation and traction,” Journal of terramechanics, vol. 44, no. 2, pp. 133–152,
2007.
[15] K. Skonieczny, S. J. Moreland, D. Wettergreen, and W. Whittaker, “Advantageous bucket-wheel
configuration for lightweight planetary excavators,” 2011.
[16] J. A. Chambers, “Preloaded joint analysis methodology for space flight systems,” 1995.
[17] M. P. Blythe, M. P. Saunders, D. B. Pye, L. D. Voss, R. J. Moreland, K. E. Symons, and L. K.
Bromley, “Nasa space flight program and project management handbook,” 2014.
23

UIC Systems Engineering Report-signed

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to UIC Systems Engineering Report-signed

Similar to UIC Systems Engineering Report-signed (20)

UIC Systems Engineering Report-signed