ASTROMECH SERIES TWO KINEMATICAND OPERATION MODEL REPORT

• 2-3-2 Legged Transitions
• CIA
• Navigation

INDUSTRIAL AUTOMATION

ASTROMECH SERIES TWO KINEMATIC

AND OPERATION MODEL REPORT

AUTHOR: EMILY SHILLING

DATE: 18 DEC 2017

– INTERNAL DESIGN DOCUMENTATION –

PROPRIETARY, FOR INTERNAL & EDUCATIONAL USES ONLY,

NOT FOR PUBLIC RELEASE WITHOUT PRIOR WRITTEN CONSENT

Contents

1.    BACKGROUND    2

2.    PURPOSE    2

3.    DESCRIPTION OF SYSTEM    4

    4

4.    SCOPE    5

5.    TASK / CONFIGURATION DEFINITION    7

Configurations:    7

Tasks:    7

6.    REQUIREMENTS    7

7.    ASSUMPTIONS    8

8.    APPROACH    8

9.    VALIDATION PLAN    9

10.    MATLAB Model    10

11.    Kinematic Model    10

12.    REFERENCES    12

APPENDIX A – DIMENSIONS    13

APPENDIX B    17

1. BACKGROUND

   1. The R2 series of Astromechs was designed to operate with forward deployed units on and off spacecraft ranging in size from stunt fighters to corvettes. Their primary purpose was spacecraft maintenance and repair but they also served to augment the onboard computer and navigation systems of smaller spacecraft (Reference 1). In these rolls the astromech droid was required to load and unload from stunt fighters (An X-wing being the most common platform of this type currently in inventories), freely navigate around a hangar bay or forward operating base and can place a manipulator precisely in an interface port to facilitate the exchange of analytical and mission based data.

2. PURPOSE

   1. This study was primarily focused on the tasks required for an Astromech that was freshly unloaded from an X-wing to report its spacecrafts status to the main computer via a wall outlet and return to the X-wing in preparation for its next mission (Figure 2.1). To complete this assignment the astromech transitioned from its two-legged stationary configuration into its much more mobile three-legged mode. It then performed a route optimization to navigate from the fighter to the nearest data port located on the hangar wall. Unfortunately, the hangar bays was congested with random pieces of cargo and other support equipment, which create a navigational challenge for the droid. Once located in front of the data port the droid’s computer interface arm (CIA) was deployed and arm’s end effector (CIAE) was precisely insert the into the wall receptacle. Once complete with its tasking the droid reported back to its fighter and configure itself into its 2-legged mode in preparation for reloading.

Figure 2.1-Typical Forward Operating Base Hangar

1. DESCRIPTION OF SYSTEM

   1. The R2 series Astromech droid under study was is essentially a 18in diameter cylinder capped by a half sphere dome (figure 3.1). The entire unit measured roughly 42in in height and could be configured in either a 2legged (Figure 3.2) or 3-legged (Figure 3.3) mode. During the transition from the 2-legged to 3-legged (2-3) mode a center foot was extended with a travel of roughly 8.85in resulting in a tripod configuration. From the droid’s body the CIA was deployed and was able to adjust the CIAE’s relative position along its length by up to 6 in.

Figure 3.1 – Main Components

Figure 3.2 – 2-Legged Mode

Figure 3.3 – 3-Legged Mode

Figure 3.4 – Top View

1. An Astromech droid consisted of five primary components, a hemispherical dome, a cylindrical body, two outer legs and a retractable center foot (Figure 3.4). The legs could pivot and adjust between 2 and 3 legged modes by rotating about their shoulders’ and ankles’. The center ankle rotated as well to allow the bottom of all three feet to remain coplanar against the floor. The shoulders, center and outer ankles and center foot extension were all driven independently. Typical 2-3 and 3-2 transitions required 2-3 sec, as defined by references to the droid’s cinematic counterpart. The dimensions of a typical R2 Astromech are provided in Appendix A. The degrees of freedom (DOF) of the droid are indicated in figure A2 and A3. Reference frame assignments, axis assignments, origins and center of masses are presented in Appendix B.

2. Propulsion was provided by independent motor drive systems located in each of the two outer feet. Zero radius turns were implementable through traditional tank style drive control of the outer feet. The center foot contained a free caster or omni-directional ball and allowed for unencumbered movement in all directions. The center foot was unpowered. The droid was assumed to have a radius of 40.4in about a point directly between the centers of the two outer feet (figure 3.1). A safety margin was implemented by utilizing a 50in radius for motion planning.

Figure 4.1 – Turn Radius and safety bubble

1. The Astromech stores a Computer Interface arm within its right vertical body compartment. This arm is deployed into a horizontal (in reference to the ground plane) position. It is not adjustable in height as the interface height is standardized with the wall ports. It is extendable along its length by up to 6 in from the fully retracted position allowing for insertion and seating of the computer interface arm end effector into the wall port. The arms dimensions are shown in Appendix A but it should be noted that the arm is canted outboard by 10.49 deg from a line running from front to back of the droid. This angle adds additional requirements to the droids approach to the outlet, complicating motion planning.

1. ASSUMPTIONS

   1. Mass was uniformly distributed unless otherwise noted.
   2. Joints and all interfaces/mechanisms were perfect. They were infinitely strong, infinitely precise, infinitely accurate and frictionless.
   3. The structure was perfectly ridged, except at desired joints. There was no motion or deflection outside of defined joints.
   4. During transition, if center of gravity remained within the bounding polygon of the two outer feet, the droid was assumed to be stable. If the center of gravity fell outside the fore/aft line of the outer feet, the droid was assumed to fall.
   5. The droid was provided with and maintained perfect situational awareness of all obstacles. It knew the exact position and velocity of itself and obstacles at all times.
   6. The “tank” style control scheme of the feet was automatically handled. If the droid was commanded to move or rotate, the coordination of the feet motors was handled as a black box (There is room here for future study but was limited due to time available).

2. REQUIREMENTS

   1. Requirements of the study were as follows:

2-3-2 Legged Transitions

1. The droid could not fall over during transitions
2. The droid remained quasi-statically stable throughout its transition
3. Beginning and end states / positions agreed with the dimensions stated in Appendix A.
4. Transition movements agreed, to the max extent possible, with the visual astatic presented in the Star Wars films.

CIA

1. The computer arm approach angle (As measured about an axis perpendicular to the ground plane) did not exceed 2 deg.
2. The computer arm was able to touch the desired wall location within the extendable reach of the arm from the position resultant from the navigation phase.

Navigation

1. The droid was able to navigate between points on a flat plane without impacting sudorandom obstructions
2. The droid was able to control its angle of incidence with walls and obstructions to facilitate interfacing of the Computer Arm.

1. TASK / CONFIGURATION DEFINITION

   1. There were three available configurations of the droid. These were the following:

• 2-Legged: Center leg retracted, outer legs parallel with vertical axis of body (figure 5.1).
• 3-Legged: Center leg extended, outer legs angled 36 deg toward the back of the droid’s body from the 2-Legged reference position (figure 5.2).
• 3-Legged, Arm Extended: Same configuration as 3-Legged but with the computer interface arm extended (figure 5.3).

Figure 5.1 – 2 Legged      Figure 5.2 – 3 Legged         Figure 5.3 – 3 Legged, Arm Extended

1. The study was broken into subsets of the overall mission data delivery task. Initial condition were that the droid was in 2-legged mode, stationary and located next to a parked X-wing Fighter. From this initial condition, the following tasks were performed:

   Task 1: Reconfigure from 2-Legged to 3-Legged mode

   Task 2: Navigate, in 3-Legged mode, to wall outlet

   Task 3: Extend CIA

   Task 4: Insert CIAE into outlet

   Task 5: Remove CIAE from outlet

   Task 3D: Stow CIA

   Task 2B: Navigate back to the start position

   Task 1B: Reconfigure from 3-Legged mode to 2-Legged mode.

1. Kinematic Model Construction

   1. The kinematics model of the Astromech was constructed utilizing 10 variables (Table 71) and nine transformations (Condensed to an equivalent of 8 transforms, Table 7-2). Origin definitions and visual representations of axis are available in Appendix C. Fixed values and offsets were determined from CAD models of an Astromech and are presented in Appendix A and B. The results of the transformation matrices were verified and validated against measurements from a fully rendered 3D model within a CAD environment. When able, the Denavit–Hartenberg convention was utilized to specify the transformations.

Table 7-1 – System Variables

Table 7-1 – Transformation Matrices

Note:

1) Non DH transform utilized to position (Pos) and orient (q1) the droid on a 2D plane.

2) The DH convention did not work with only one transformation matrix. Two transforms in DH form were utilized to construct an equivalent single transform.

3) Performed an axis swap to result in a more intuitive A₆

1. To empower analysis throughout this study a Matlab script was created to model the kinematics:

   

This script utilized a custom transform builder called myDH which has be verified throughout this course and is presented below:

1. For the analysis involved in the CIAE placement, the transformation matrix of the CIAE was precalculated. Since the CIAE was only utilized when the droid was in the 3-legged configuration with the CIA deployed q₃ through q₅ were constants. The resulting transformation matrix is as follows:

End Effector Transform (q₃ = 18; q₄ = 36; q₅ = 18):

1. To facilitate the analysis of the droid’s stability during configuration transitions, transformations were required for the center of gravity of each component. For analysis involving masses and center of gravity, the CIA and CIAE were ignored. The required transformation were constructed utilizing the offsets defined in table 7.2 in their corresponding reference frames:

Table 7.1 – Center Of Gravity Offsets

1. Simulink Model Construction
   
   1. A Simulink model of an Astromech was constructed. This model utilized both a Simulink model and a separate Matlab script. The script was used to programmatically define parameters of the model and to control the movement of joints with respect to time. The script transitioning the droid from 2 to 3 legs and back is as follows:

1. To import the data into Simulink the above program had to be run first, prior to running the Simulink simulation for the first time. This would initialize the variables and values. In all, 14 parameters were imported into Simulink. Time varying values were importing from the timeseries defined in the Matlab script above using blocks constructed as below:

Figure 8.1 – Timeseries input

If the values were in units of degrees, the subsystem block was:

Figure 8.2 – Degrees to Radians Subsystem

If the values were in units of inches, the subsystem block was:

Figure 8.3 – Inch to Meters Subsystem

1. To allow Simulink to offset a reference frame by a variable amount (One not known within Simulink) the offsets had to be applied to a Cartesian joint. Static values for CG were imported into Simulink utilizing the following block construct:

   

Figure 8.4 – CG values from Matlab

1. Masses were import into the Simulink model via a very simple subsystem:

   

Figure 8.5 – Mass values from Matlab

1. The efforts for the construction of the primary Simulink model took a disproportionate amount of time as efforts were severely hampered by a steep learning curve. However, a successful model was constructed. In particular the purpose of the model was to evaluate the CG of the entire droid system throughout the transition from 2 to 3 leg and back. Utilizing the components discussed prior the resulting model was as follows:

Figure 8.6 – Main Transition Model

1. The model begins in the lower left corner with the setting of the world frame, mechanism configuration and solver. Additionally, in the world frame a visual of the flat Hangar floor is added. Flowing right, the next component is the A1 transform block. This block is a planar joint and can take in the X, Y position of the droid as well as its orientation. Although never fully realized, this was the mechanism for driving the droid around the simulation to generate insightful visuals of the results of the droid’s path planning. Straight up from the A1 joint the model builds the A2 transform minus the q2 angle. The q2 revolute joint is connected immediately adjacent and above the transform. Off this connection are two signals. This branch off to place the left and right foot in their proper orientation and location relative to the 2^nd reference frame. The q2 revolute joint takes in its value from the “Joint Values From Matlab” block located on the far left of the model. Also on this local line segment a signal is routed all the way to the top of the model to a subsystem block labeled “Outer Foot CG” which takes the current reference frame as an input. The remaining joints and bodies follow this pattern.

2. The center of mass for the system was calculated by referencing each body’s reference frame and passing it to the “Calculate CG” subsystem via its corresponding CG offset subsystem as indicated in Section 8.3.

Figure 8.7 – CG calculator

Masses for this calculation were imported as indicated in section 8.4. Since the droid was approximately symmetric from side to side, the CG offset in the Y direction in the 1^st reference frame was ignored. Additionally, since the vertical position of the CG of the Droid does not effect the droid tipping over in a quasi-static analysis, it was ignored as well. For these reasons, only the X position of the droid’s CG was found and plotted. The X position of the CG was both plotted and feed back to the main Simulink model. Within the main Simulink model, the X position was feed to a “CG X” planer joint at the bottom right of the Main Transition Model. This planer joint was then connected to a red rectangular body (figure 8.8) used to display the CG within the 3D simulation.

Figure 8.8 – CG presentation within simulation

1. Analysis Of End Effector Positioning

   1. To facilitate the rapid secure transfer of mission data, the astromech droid had to physically connect with an Interface Port on the hangar wall. The interface port is a standard component and is always mounted flush with a wall surface 28.0 in above the floor. The droid had to be positioned and oriented correctly to interface properly. Given the known location of a port, the position of an astromech was calculated via the following equation algorithm.

      Where P_Port is the 3 vector representing the Ports location. To allow for some error in position, q₆ was set to a midrange value of 3in to allow for both retraction and extension. This resulted in:

=>

To determine the location that the droid must go to and in what orientation it must be in requires two primary steps. First, the orientation of the droid (q₁) must be solved for. Knowing the wall that the port is located on, the normal of the wall and hence the port axis can be computed. The hangar walls were represented by a 2D polygon with its points defined in a clockwise order. The droid was assumed to be contained within the polygon. Given the two points defining the line segment representing the wall with the port, p1 and p2, the vector v was equal to P2-P1. The world z direction was z = . The following equation was used to determine the normal of the wall and its angle of incidence in world coordinates:

Given the normal calculated above, the orientation of the droid would be:

Example / Verification of Orientation Equations:

Given the following v₁ and initial orientation of q₁=0 the required rotation was found by:

1. Once the orientation was known the location of the droid in world coordinates was determined by calculations utilizing the first two rows of the 4^th column of the and the port location

    

Example / Verification of Positioning Equations:

Given the same port orientation as in the prior example and a port location of p = [0in -50in 28in] the position of the droid would be computed as follows:

1. Analysis of CG Location During 2 to 3 and 3 to 2 Leg Transition

1. The Simulink model constructed earlier was utilized to analysis the CG of the droid. It was assumed that if the CG ever shifted beyond 6.00 in, the CG would fall outside of the base of the outer feet and the droid would tip over. Leaving the CGs and masses as described in Appendix B (Stock Configuration) several sequences of joint movements were attempted. Two such sequences, are shown below.

   Sequence 1

Sequence 2

These resulted in the following graph:

From these trials, it was found that the time scale did not effect anything and this concurs with the kinematic approach taken and the ignoring of dynamic aspects of the model. It can also clearly show that no amount of manipulating of the sequence will ever result in the CG not shifting outside of the allowable amounts. The stock configuration will always tip over. In order to change the CG shift, either the masses of components or the CG locations had to be adjusted. The Body weighted the most and had the largest volume. After studying the CAD models, it was determined that CG shifts within the body would be supportable in future builds of an Astromech as most of the heavy components of the body are located near if not in the dome of the droid. It was also determined that CG shifts only up and down and front to back would help solve the tipping problem. This meant, that in the reference frame of the body, only the X and Y axis in this frame mattered. At this point, it became apparent that further analysis outside of the Simulink model was required. The following Matlab script was used to determine the equation for the Astromech CG in the 3 leg mode as dependent on the Body’s CG location in its coordinate system:

This generated the following system of equations:

As the Droid’s ability to remain standing was only dependent on the CG in the X axis, only the first equation was required:

Solving this equation for Y showed the boundary of allowable CG locations:

From the above figure the range of allowable CG locations that will result in a stable 2 to 3 leg and 3 to 2 leg transition can be determined.

1. SCOPE

   1. The project took roughly 50 hours and was primarily limited in scope due to man hour constraints. The project focused on modeling and not on actual hardware development. As such, assumptions were made on initial mass distribution. Exact dimensions of the system where estimated when real numbers were not yet reasonably available (Appendix B). The CAD models used for this project were already complete.

   2. Modeling of the Astromech’s configuration transitions, navigation through the hangar bay and interfacing with the wall outlet will be primarily modeled in Matlab using techniques shown in lecture as well as insights from other available sources on the subject. The four primary tasks, the 2-3 and 3-2 transition, computer arm placement / manipulation and navigation will be addressed in that order with the hopes of developing each to a reasonable state.
   1. The 2-3 and 3-2 transition analysis will begin assuming quasi-static stability with the hopes of further developing a dynamic analysis. During the quasi-static analysis the droid will be assumed to remain standing as long as the center of gravity remains within the bounding polygon of the outer feet.
   1. As path planning and optimization have not been covered in this course, it offers the most risk to the project. Preliminary research into the area indicates that there are sufficient resources available to build a working knowledge of the subject in time and to an adequate depth for this project (Reference 2-4). Path optimization will most likely heavily depend on the robotics toolkit included in Matlab. Preliminary work has shown that there are several tutorials on path optimization in Matlab available on the Mathworks website. Optimal path will be determined by minimal distance. Motion will be planned utilizing a pure pursuit methodology with a minimal turn radius of 0.0 in, perfectly about a point directly between and centered with the two outer feet. The droid will be assumed to have a radius of 40.4in about this point (figure 4.1). A safety margin will be implemented by utilizing a 50in radius for this study.

2. APPROACH

   1. Efforts will begin with the importing of existing CAD drawings into Matlab. Coordinate frames/axis have already been assigned for all joints. Masses and component center of gravities have been estimated from CAD models. Initial efforts will focus on the calculation of required transformation matrices. Following this, investigation and refinement of the 2-3 and 3-2 transitions will be performed.
   2. With a predefined wall outlet location (Where the end effector must be placed) the required location of the droid will be calculated relative to the outlet (an inverse kinematic problem). The angle of incidence and extension length will be accounted for. From this, the position the droid must navigate to for successful interface with the outlet will be determined.
   3. Utilizing a predefined start and end position and obstacle locations, initial path optimization will be developed. Once basic navigation is working, random seeding of obstacles and wall outlet locations will be used to challenge and further develop the algorithm. Initial development will be centered around static obstacles. Implementation of moving object avoidance will for now remain a stretch goal of the project.

3. VALIDATION PLAN

   1. Validation that the constructed model operates as intend will be conducted through measures of how well the requirements derived above are met and by verifying the individual tasks presented in section 5 are performed correctly. It is the hope of the author that the individual tasks can be strung together in one simulation, but reserves that as a stretch goal. The validity of navigational solutions will be assessed through the analysis and presentation of multiple obstacle maps along with calculated trajectories. Successful navigation will be determined based on the automatic selection of the optimized route and avoidance of collisions. Verification of the 2-3 and 3-2 transitions will be assessed through plots of the cg position and joint angles with respect to time for the quasi-static analysis. Satisfactory compliance for the Computer Arm interface task will be measured through error measurements between desired outcome/position and modeled results. True verification/validation of the models constructed cannot take place until a real unit is constructed and tested in the field but this model will serve to highlight possible future difficulties and areas requiring further study.

1. REFERENCES

   1. Astromech droid, Wookieepedia, http://starwars.wikia.com/wiki/Astromech_droid
   2. Path Following for a Differential Drive Robot, Mathworks,
   3. Path Planning in Environments of Different Complexity, Mathworks, https://www.mathworks.com/help/robotics/examples/path-planning-in-environments-of-different-complexity.html
   4. Work with Mobile Robotics Algorithms in MATLAB, Mathworks, https://www.mathworks.com/videos/work-with-mobile-robotics-algorithms-in-matlab-100084.html

APPENDIX A – DIMENSIONS

Figure A1 – Side Dimensions (in, deg)

Figure A2- Front Dimensions (in)

Figure A3 – Computer Interface Origin (in)

Figure A4 – Computer Interface Arm (in)

APPENDIX B – Component Specifics

	ID: Left Foot Volume: 501.3 in^3 Mass: 27.7 lb Center of Mass: [0.00, -2.10, 1.00] Origin in A2: [0 0 -11.07]
	ID: Right Foot Volume: 501.3 in^3 Mass: 27.7 lb Center of Mass: [0.00, -2.10, 1.00] Origin in A2: [0.00 0.00 11.07]
	ID: Left Leg Volume: 476 in^3 Mass: 26.3 lb Center of Mass: [6.50, 0.00, 3.30] Origin in A3: [0.00 0.00 7.58]
	ID: Right Leg Volume: 476 in^3 Mass: 26.3 lb Center of Mass: [6.50, 0.00, 3.30] Origin in A3: [0.00 0.00 -7.58]
	ID: Body Volume: 6705.7 in^3 Mass: 371.0 lb Center of Mass: [0.00, 0.00, -2.04] Origin in A4: [0.00 0.00 0.00]
	ID: Center Leg Volume: 118 in^3 Mass: 6.5 lb Center of Mass: [0.00, 0.00, 3.00] Origin in A7: [0.00 0.00 0.00]
	ID: Center Foot Volume: 237 in^3 Mass: 13.1 lb Center of Mass: [0.00, -2.80, 0.00] Origin in A8: [0.00 0.00 0.00]
	ID: Computer Interface Arm (CIA) Volume: 19.32 in^3 Mass: 1.1 lb Center of Mass: [4.93 0.00 1.76] Origin in A5: [0.00 0.00 0.00]
	ID: Computer Interface Arm Effector (CIAE) Volume: 3.80 in^3 Mass: 0.2 lb Center of Mass: [0.00, 0.00, 7.62] Origin in A6: [0.00 0.00 11.8]

APPENDIX C – Transform and Axis Visualization

For all diagrams, Red = X direction, Green = Y direction, Blue = Z direction and Gold = positive rotation.

A1:

A2:

A3:

A4:

A5:

A6:

A7:

A8: