Table of Contents

• Appendix A - Prognostics Architecture
• Appendix B - Precomputed Robotic Arm Force/Torque Tables
• Appendix C - Design of ow_regolith

Appendix A - Prognostics Architecture

The goal for a prognostics implementation is to predict accurately the occurrence of a defined event E with respect to the states, parameters, and inputs of the system. An event as the earliest instant that some event threshold ,

where changes from the value 0 to 1. That is, the time of the event kE at some time of prediction kP is defined as

For systems health management, the event TE is defined by a set of performance constraints that define the safe operating states of the system, based on x(k), θ(k), and u(k). For a discharge cycle of the battery, the event of interest is the end of the discharge of the battery (EOD), defined by when the battery state of charge hits a voltage threshold VEOD. In this case, TE is defined by V < VEOD, that is, when the battery voltage is less than the predefined cutoff voltage, EOD is reached and TE evaluates to 1. After the event is triggered, a decision can be taken next for tasks to be performed based on the health state of the system.

In the simulation, a model-based prognostics architecture is adopted and implemented, in which there are two sequential problems: (i) the estimation problem, which requires determining a joint state-parameter estimate based on the history of observations up to time k, and (ii) the prediction problem, which, at time kp, determines a probability distribution for the time remaining until the end of discharge, ∆kE.

As shown in the prognostics architecture, Figure 4, at discrete time k, the system is provided with inputs uk voltage, current etc and provides measured outputs yk. The estimation module uses this information, along with the battery system model, to compute the joint-state parameter estimate p(x(k),θ(k)|y(k0:k)). The prediction module uses the joint state-parameter distribution and the system model, along with estimated future inputs, to compute the probability distribution p(kE(kP)|y(k0:kP)) at given prediction times kP. Full details of the model are available in [Daigle2013].

Prognostics Architecture

Appendix B - Precomputed Robotic Arm Force/Torque Tables

The force/torque lookup table is a .csv file. Columns 1 to 4 contain values of parameters that influence the terrain dynamic response. Columns 5 to 7 provide the force value in N, and 8 to 10 the torque in N·m, corresponding to the specific values of those parameters. Column 1 includes values between 1 and 3, which refer to the material type: it is equal to 1 if the bulk material is made of ice fragments, 2 if the bulk material is snow, 3 if it is sand. In column 2, the bite depth in m is specified. The table has four possible values of the bite depth: 15 mm, 9 mm, 5 mm, 3 mm. Column 3 has integer values from 1 to 5 which correspond to the pass number. Finally, column 4 contains the trenching distance covered by the center of mass of the scoop since its first contact with terrain, measured in m. While the material type and pass number are always integer quantities, the bite depth and covered distance might have values different than the ones specified in the lookup table. When current values of the bite depth and covered distance do not coincide with the ones in the lookup table, the plugin selects the row with the closest value.

Ice, snow and sand terrains are defined by their specific bulk material parameters that dictate the particle-particle and particle-scoop interaction, as well as the individual particle features. The value of these parameters, reported in the following table, have been determined as a result of extensive research and experimentation, and conveniently chosen to minimize computation time.

	Snow	Ice fragments	Sand
Material density	300 kg/m^3^	900 kg/m^3^	1600 kg/m^3^
Shear modulus	1e+07 Pa	1e+07 Pa	1e+07 Pa
Poisson ratio	0.36	0.36	0.25
Particle-particle rolling friction	0.05	0.05	0.05
Particle-particle static friction	0.58	0.58	0.35
Particle-particle restitution coefficient	0.88	0.88	0.88
Particle-scoop rolling friction	0.05	0.05	0.04
Particle-scoop static friction	0.58	0.58	0.3
Particle-scoop restitution coefficient	0.7	0.7	0.5
Cohesion	0	0	0
Interaction model	Elastic, non-cohesive	Elastic, non-cohesive	Elastic, non-cohesive
Gravitational acceleration (magnitude)	1.3 m/s^2^	1.3 m/s^2^	1.3 m/s^2^

Snow and sand particles are represented by single spheres with a 3.5 mm diameter. Ice particles consist of a composition of four 3.5 mm diameter spheres, to resemble a tetrahedral shape (see figure below).

The provided lookup table allows for a very accurate simulation of the interaction between scoop and terrain when the given environment characterization and scoop configuration.

Appendix C - Design of ow_regolith

ow_regolith is responsible for spawning regolith particles into the scoop as it digs. To accomplish this, the package makes use of multiple ROS Topics and Gazebo-ROS services. The interactions between ROS topics, services, and the various subsystems of ow_regolith is described in the Subsystem Diagram section. An overall architecture of the package is provided in the Class Diagram section.

Subsystem Diagram

The regolith_node sets up the ROS interface and initializes the RegolithSpawner, which is responsible for

• maintaining the ROS interface,
• implementing the ROS services /ow_regolith/spawn_regolith and /ow_regolith/remove_regolith,
• making the appropriate method calls whenever a modification to the terrain occurs, and
• removing regolith from the simulation when it contacts the terrain.

ModelPool is initialized by RegolithSpawner. It sets up the interface with ROS-Gazebo to spawn/delete models, and apply/remove wrenches, and manages all regolith models spawned by ow_regolith.

DigStateMachine is initialized by RegolithSpawner. It monitors the status of terrain modification and the orientation of the scoop to estimate the phase of digging that is occurring. The phases of digging are

Dig Phase	Description
NotDigging	The scoop is neither contacting terrain nor in a digging orientation.
Sinking	The scoop has made contact with the terrain and is pitched downward into it.
Plowing	The scoop is level with the terrain and moving horizontally through it.
Retracting	The scoop is pitched upward and is exiting the terrain, concluding the dig.

The dig phase is used to apply/remove psuedo forces on regolith particles to keep them in the scoop during a dig. It is also used to reset the tracked volume to zero at the end of each dig, so that volume is not carried over between digs.

Class Diagram

For a more detailed view of the architecture of ow_regolith the following class diagram is provided.

---

[Daigle2013] M. Daigle and C. Kulkarni, “Electrochemistry based Battery Modeling for Prognostics”, Annual Conference of the Prognostics and Health Management Society (PHM 2013), October 2013, New Orleans, LA.