Mobile manipulator systems and methods

Abstract

An agitator for controllably agitating a workstation and / or workpiece includes a base practically immobile with respect to a global reference frame; an actuator mounted to the base; a controller configured to agitate the actuator; and a sensor configured to sense a position of a distal end of the actuator.

Description

[0001]MOBILE MANIPULATOR SYSTEMS AND METHODS Related Applications This application claims the benefit of U.S. Provisional Patent Application Serial No.63 / 635,212 (filed April 17, 2024), which is herein incorporated by reference in its entirety. Federally-Sponsored Research and Development This invention was made with United States Government support from the National Institute of Standards and Technology (NIST), an agency of the United States Department of Commerce. The Government has certain rights in this invention. Copyright Notice This patent disclosure may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves any and all copyright rights. Field of Invention The present invention relates generally to robotics, and more particularly to mobile manipulators. Background Mobile manipulators, which integrate a robotic manipulator with an autonomous mobile base, have the potential to augment automation by combining the capability of navigation with complex manipulation to support unstructured and dynamic environments. Targeted applications include manufacturing large-scale parts commonly encountered in the aerospace, energy, shipbuilding, and transportation sectors. Summary of Invention While autonomous mobility no longer restricts the robotic manipulator to working at a single, rigidly fixtured workstation or workpiece, the increased flexibility introduces new sources of position and orientation uncertainty, and manufacturing processes of large-scale parts with complex, curved surfaces require high repeatability and accuracy. Standardized measurement methodologies, including a configurable measurement artifact to simulate dynamic manufacturing operations, is described herein to identify and evaluate these sources of performance uncertainty. A workpiece agitator may be used to demonstrate the performance evaluation of mobile manipulation performance in application scenarios where the workstation or workpiece is physically disturbed during operation or where rapid registration between distant locations along the same workpiece is required. The agitator may include a linear actuator mounted to an effectively-immobile base (e.g., a wood pallet and weighted down by fitness bumper plates). The actuators may be controlled via a system-on-board computer outfitted with two four-channel relay boards, e.g. Additionally, a closed-loop mobile manipulator control system that integrates feedback from an optical tracking system presents a new test implementation to demonstrate the performance evaluation of mobile manipulation performance in application scenarios where the workstation or workpiece is physically disturbed during operation or where rapid registration between distant locations along the same workpiece is required. Exemplary embodiments provide a standardized, reproducible test method for evaluation in a variety of simulated application spaces. According to one aspect of the invention, an agitator for controllably agitating a workstation and / or workpiece includes a base practically immobile with respect to a global reference frame; an actuator mounted to the base; a controller configured to agitate the actuator; and a sensor configured to sense a position of a distal end of the actuator. Optionally, the base includes removable weight configured to, while attached, weigh the base down, making the base practically immobile and, while removed, allow the base to be practically moveable. Optionally, the controller is a system-on-board computer outfitted with two four-channel relay boards. Optionally, the actuator is a linear actuator. Optionally, the distal end of the actuator is rotatably coupled to a workstation and a proximal end of the actuator is rotatably coupled to the base. Optionally, the agitator includes one or more sensors configured to determine an extension of the actuator. Optionally, the sensor includes a linear encoder. Optionally, the sensor includes a string encoder or potentiometer. Optionally, the sensor includes a ground truth reference sensor. Optionally, the ground truth reference sensor includes a plurality of optical tracking system registers at a distal end of the actuator for optically tracking movement of the actuator with respect to the global reference frame. The foregoing and other features of the invention are hereinafter described in greater detail with reference to the accompanying drawings. Brief Description of the Drawings FIG.1 shows a schematic diagram of an exemplary agitator. FIG.2 shows a block diagram of a high-level control flow between the two closed-loop controllers for implementing coarse autonomous mobile robot cart transporter posing (navigation), and fine docking near the configurable mobile manipulator assembly and the manipulator controller to perform mock peg-in-hole- assembly through detection of the assembly fiduciaries using a retro-reflective laser sensor and emitter. FIG.3 shows a block diagram of the control algorithm design for coarse autonomous mobile robot cart transporter posing. Note that fvand fotsdenote the control frequencies of the autonomous mobile robot cart transporter controller and optical tracking system, respectively. Additionally, ξ is used to denote poses in a described representation. FIG.4 shows a block diagram of the control algorithm for refined docking near the configurable mobile manipulator assembly with autonomous mobile robot cart transporter heading corrections. Note that fvand fotsdenote the control frequencies of the autonomous mobile robot cart transporter controller and optical tracking system, respectively. Additionally, ξ is used to denote poses in a described representation. FIG.5 shows a block diagram showing the closed-loop manipulator controller design for the Cartesian / linear servo pose controller. Note that fmand fotsdenote the control frequencies of the manipulator controller and optical tracking system, respectively. FIG.6 shows a network diagram showing optical tracking system integration with the mobile manipulator-on-a-cart and labeled with software libraries needed to implement closed-loop mobile manipulator control. Note the peer-t-peer time synchronization with GPS as the primary time reference enabling UTC timestamping of manipulator and autonomous mobile robot cart transporter position data from the optical tracking system for closed-loop control of the mobile manipulator. FIG.7 shows a diagram of the coordinate system transformations needed to conduct a 6 DoF registration between the manipulator cart base and the configurable mobile manipulator apparatus. FIG.8 shows a diagram of the 6 DoF coordinate system transformations needed for closed-loop to register between the end-of-arm-tool to the manipulator cart base. FIG.9 shows a diagram of the 6 DoF coordinate system transformations needed for closed-loop fine positioning of the end-of-arm tool over the assembly fiduciaries. FIG.10 shows a diagram showing the 6 DoF coordinate system transformations needed to command the autonomous mobile robot cart transporter to dock with the configurable mobile manipulator apparatus. FIG.11 shows a diagram showing the 3 DoF coordinate system transformations needed to command the autonomous mobile robot cart transporter to dock with the configurable mobile manipulator apparatus. FIG.12 shows a diagram of homogeneous transformations in different coordinate systems needed to calibrate the unknown coordinate transformation between the autonomous mobile robot cart transporter map and the optical tracking system. FIG.13 shows a block diagram of an exemplary computer system. Detailed Description Localization performance of mobile manipulators in unstructured environments and insufficient pose accuracy / repeatability in the mobility component have been cited as challenges preventing the adoption of mobile manipulators for such tasks. Furthermore, the complex, curved shapes associated with many large- scale components also require a high degree of manufacturing accuracy. Exemplary methods may independently validate measurements obtained solely using control logs and local sensors against ground-truth reference measurements. For this purpose, a ground truth reference tracking system such as, for example, a laser tracking system or a motion capture Optical Tracking System (OTS) may be used as the ground truth measurement system. Exemplary performance evaluation activities use a cost-efficient, versatile test artifact, dubbed the Configurable Mobile Manipulator Apparatus (CMMA) (referred to as the Re-configurable Mobile Manipulator Artifact (RMMA) in some literature). The CMMA provides a mock-workpiece, with machined holes, to evaluate the performance of mobile manipulator peg-in-hole insertion type manufacturing tasks, and exemplary embodiments may use an exemplary CMMA or any appropriate analogue or other workstation. Performance evaluation includes intercepting retro- reflective targets with a Retro-reflective Laser Sensor and Emitter (RLS) mounted to the End-of-Arm Tool (EOAT) of the manipulator. Alignment of the RLS with the retro- reflective targets serves as analogous to peg-in-hole insertion type manufacturing tasks, and the target diameter sizes can be selected to reflect desired manufacturing performance tolerance. Described herein is a workpiece agitator to demonstrate the performance evaluation of mobile manipulation performance in application scenarios where the workstation or workpiece is physically disturbed during operation or where rapid registration between distant locations along the same workpiece is required. Exemplary embodiments may be controlled by a system-on-board computer via stacked relays and is built and programmed for automating reproducible disturbances on mobile manipulator workpieces for performance testing. Exemplary designs may use off-the-shelf parts so as to be cost-effective and easy to re-produce for mobile manipulator manufacturers, integrators, and end-users. Referring first to FIG.1, an exemplary agitator 100 includes an actuator 110 mounted to a base 120. The base 120 is preferably immobile or practically immobile with respect to a global reference frame. The actuator 110 may be controlled via a system-on-board computer 130, which may be, for example, outfitted with two four- channel relay boards. The actuator 110 may be attached to the base 120 with a support structure preferably made of a stiff material such as aluminum, that tends to minimize deflection of the actuator 110 with respect to the base 120. Preferably, the actuator 110 is a linear actuator, as depicted. However, other mechanisms may be employed for agitating the workpiece / workstation 190 including, for example, a rotating cam mechanism. Such a mechanism would enable repetitive and precise actuation and could more easily impart vibratory perturbations than a linear actuator. A cam mechanism, or other actuators, may be employed independently, or in conjunction with each other. For example, a cam mechanism could be disposed as an end-effector on a distal end (far from the agitator and close to the workstation) of a linear actuator, enabling a combination of cyclic and acyclic perturbation. If mobility is not needed in a particular application, the base 120 may be secured to a large object or ground that is fixed to a reference frame of interest, for example by being fixedly coupled to the ground, for example, by fasteners such as bolts. In applications where intermittent mobility of the agitator 100 is desirable (for example, for repositioning the agitator 100 between uses) the base 120 may be weighed down to enable friction with the environment to hold the agitator 100 relatively fixed. For example, the base 120 may be a wood pallet weighted down by weights 124, such as, e.g., fitness bumper plates. The distal end 112 of the actuator 110 may be fixedly or, more preferably, rotatably coupled to the mobile manipulator workstation. Likewise, the proximal end 114 of the actuator may be fixedly or, more preferably, rotatably coupled to the base 120. When there is a rotation of the work piece relative to the agitator 100, the actuator being rotatably coupled at distal and proximal ends allow rotations so as to not cause a torque to the actuator or other components of the system. When the load (work piece) does not rotate (e.g., in a pure linear move relative to the actuator), or the rotation is minimal, the actuator rotation (and therefore rotatable couplings) are not necessary. The distal end 112 of the actuator 110 may also include OTS markers 116, enabling the OTS to easily track the position and orientation of the distal end 112 of the actuator 110. The base 120 may also include such a marker to verify the degree to which the base 120 is immobile or fixed with respect to the OTS reference frame. The agitator 100 may include one or more sensors for determining the extension of the actuator 110, including, e.g., a linear encoder 122 and / or a string encoder or potentiometer 124. An exemplary closed-loop control method 200 using pose feedback from an OTS is shown at FIGs.2-5. This control system, when used after docking to register a mobile manipulator to a known, fixed location, can serve as a reference of comparison with or for the possible development of alternative coordinate registration methods that use on-board sensing. For example, use of an OTS may be faster and more accurate than conventional laser-based coordinate registration methods (i.e., spiral search, bisection, edge detection, and stochastic Kalman filters) or provide a ground-truth reference to compare with closed-loop feedback from an on-board vision system. Referring now to FIG.6, an exemplary network diagram shows OTS integration with a mobile manipulator-on-a-cart and is labeled with software libraries to implement closed-loop mobile manipulator control. Precision Time Protocol (PTP) time synchronization with GPS may be used as the primary time reference enabling UTC timestamping of manipulator and cart position data from OTS for closed-loop control of the mobile manipulator. Conventional systems may use Network Time Protocol (NTP) to synchronized the OTS, manipulator, and mobile cart controller systems. In a conservative estimate, NTP provides 100 ms to 1 s synchronization precision between nodes in a wireless environment. In contrast, exemplary designs include: (a) reduced number of wireless hops, (b) reduced one-way path delay variability using hardware timestamping at the network nodes where feasible by replacing (1) switches with transparent clocks, (2) OTS node with Precision Time Protocol (PTP) Peripheral Component Interconnect Express (PCIe) card for hardware timestamping of Ethernet packets, and (3) providing a Linux-based onboard computer and controller module also with hardware times-tamping and a real-time clock. Referring now to FIG.7, to implement the registration between the manipulator cart base 310 and the configurable mobile manipulator apparatus (CMMA) 320, streamed data from the OTS rigid body is used each time the manipulator cart base 310 is docked with the CMMA 320. Five coordinate frames are involved, including the OTS coordinate frame 331 (denoted OTS), the manipulator cart base coordinate frame 311 (denoted cbase), the CMMA coordinate frame 321 (denoted cmma), the assembly fiducials coordinate frames 341, 351 (denoted afiwhere i ∈{1,2,3,4} is the fiducial target number), and the coordinate frame 361 of the docking goal 360 of the manipulator cart base (denoted dock). Since the Cartesian pose and linear servo API calls of ur_rtde expect the pose of the end-of-arm tool (EOAT) to be specified relative to the manipulator cart base, the goal is to determine the coordinate transformation chain needed to express the commanded pose of the EOAT to intercept the assembly fiducials 340, 350 using a retro-reflective laser sensor and emitter (RLS). This pose is denoted fi}where i ∈{1,2,3,4} is the fiducial target number and is interpreted as “the pose of the assembly fiducial relative to manipulator cart base”. Note that since the assembly fiducials are rigidly fixtured to the CMMA, the pose of the assembly fiducials relative to the CMMA, denoted{cmma}ξ{a fi}where i ∈{1,2,3,4}, is fixed and known a priori. Furthermore, the height and yaw components of{cmma}ξ{a fi}may be set to arbitrary constant values, while the roll may be set constant to π rad such that the commanded EOAT pose would face downward with the RLS pointing towards the assembly fiducials. Additionally, since the autonomous mobile robot cart transporter (AMR-CT) controller mentioned below requires the ability to detect when the cart has arrived at the docking goal, an additional registration may be needed to determine the measured pose of the docking goal relative to manipulator cart base (i.e.,{cbase}ξ{dock}). The coordinate transformation describing the pose of manipulator cart base relative to the OTS, denoted,{OTS}ξ{cbase}, and the pose of the CMMA relative to the OTS, denoted,{OTS}ξ{cmma}, may be streamed directly from the OTS. Therefore, the ideal pose of the EOAT relative to the manipulator cart base such that the EOAT can intercept the assembly fiducials may be determined by Eq.1. Now, to determine the additional registration between manipulator cart base and the docking goal,{cbase}ξ{dock}, an additional relative pose describing the pose of the docking goal relative to the CMMA, denoted{cmma}ξ{dock}, may be defined. The transformation,{cmma}ξ{dock}, may be fixed and pre-defined, which means{dock}ξ{cbase}is determined by Eq.2. To implement the coordinate system registration between the EOAT and the manipulator cart base, the following coordinate systems depicted in FIG.8 are needed. Let eoat denote the coordinate frame associated with the EOAT 810. The objective is to determine the coordinate transformation chain needed to express the measured pose of the EOAT relative to the manipulator cart base, denoted{cbase}ξ{eoat}, so compared to its commanded pose in orientation. Then, the relative poses,{OTS}ξ{cbase} and{OTS}ξ{eoat}, denoted the measured pose of manipulator cart base and EOAT, respectively, relative to the OTS coordinate system, and the measured pose of the EOAT relative to the manipulator cart base is given by Eq.3. To implement the coordinate system registration between the EOAT and the CMMA, the following coordinate transformations depicted in FIG.9 are needed. The goal is to determine the coordinate transformation chain needed to express the ideal pose of EOAT to intercept the retro-reflective targets with the RLS, except this time relative to the EOAT coordinate frame rather than relative to the manipulator cart base. This pose was given by{eoat}ξ{a fi}where i ∈{1,2,3,4} is again the fiducial target number. This is because the Cartesian controller presented later requires this transformation to determine when the EOAT has reached the commanded pose and the Proportional-Integral-Derivative (PID) controller takes the error between the current EOAT pose and the commanded pose as input for velocity-based control. The relative pose,{OTS}ξ{cmma}, again denotes the measured pose of the CMMA relative to the OTS coordinate system, which is obtained directly from the OTS rigid body tracking. The pose,{OTS}ξ{eoat}, describing the measured pose of the EOAT relative to the OTS coordinate system is also obtained directly from the OTS. Finally, the pose of the assembly fiducials relative to the CMMA is given by{cmma}ξ{a fi} where i ∈{1,2,3,4} is the fiducial target number. Again, this pose is constant and known a priori. Therefore, the retro-reflective fiducial positions relative to the EOAT are determined by Eq.4. The coordinate transformations needed to coarsely pose the AMR-CT to dock with the CMMA are now explained and depicted in FIGs.11 (6 DoF) and 12 (3DoF). Three coordinate frames for the OTS, manipulator cart base, and the CMMA are defined and denoted OTS, cbase, and cmma, respectively. The coordinate frame of the AMR-CT itself is denoted vbase. The AMR-CT map coordinate system is represented by up to two additional coordinate frames (depending on if 3 DoF or 6 DoF are used). The first is MAP 2D, which, in the 3 DoF case, corresponds to the 2D AMR-CT map coordinate system or, in the 6 DoF case, embeds the 2D AMR-CT map coordinate system into 3D by assuming zero height, roll, and pitch. The second coordinate system is a 3D projection of 2D AMR-CT map, denoted MAP 3D, which is only needed for the 6 DoF case. Additionally, dock denotes the coordinate frame of the ideal docking goal near the CMMA. Since, the goToPoint clear-text command is used to position the AMR-CT near the CMMA, the goal is to obtain{MAP 2D}ξ{vbase}, which denotes the commanded position of the AMR-CT coordinate frame in the MAP 2D coordinate frame. The following additional relative poses are now defined. First, let{MAP_3D}ξ{vbase} and{OTS}ξ{vbase} denote the relative poses describing the commanded pose of the AMR-CT relative to the MAP 3D and OTS coordinate frames, respectively. Furthermore,{OTS}ξ{cmma}denotes the transformation describing the pose of the CMMA relative to the OTS coordinate frame, which is again given directly from the streamed OTS data. The transformation,{cmma}ξ{dock}and{cbase}ξ{′dock}, denotes the transformations describing the commanded pose of the docking goal relative to the CMMA and cart base, respectively. These transformations are fixed and pre-defined such that the front of manipulator cart base directly faced the CMMA, the center of the cart aligned with the center of the docking arc, and the cart is initially 1000 mm away from the CMMA in x. However, the difference in height between manipulator cart base and the configured height of the CMMA also needs to be factored into the height component of these transformations in the 6 DoF case. Finally,{vbase}ξ{cbase}denotes the fixed pose of manipulator cart base relative to the AMR-CT base. Therefore, for the 6 DoF case, the transformations{OTS}ξ{MAP_3D} and{MAP_2D}ξ{MAP_3D}are the only potentially unknown coordinate transformations. However, a 6 DoF calibration procedure for the transformation AMR-CT map coordinate system and OTS has been previously devised and implemented. In summary, the calibration procedure involves parking the AMR-CT at seven, level (as measured by digital levels attached to the AMR-CT) locations throughout the environment, recording pose data from the AMR-CT controller and OTS rigid body data, and applying closed-form solutions to the collected pose data to calibrate the unknown coordinate transformations. The same procedure without modification is used again to solve for{OTS}ξ{MAP_3D}and{MAP_2D}ξ{MAP_3D}, which means that the complete coordinate system transformation chain for the 6 DoF case is expressed by Eq.5. For the 3 DoF case, only the transformation that goes directly between the 2D projected OTS coordinate system and the 2D AMR-CT map (i.e.,{OTS}ξ{MAP_2D}) is potentially unknown. However, the calibration procedure from the 6 DoF case is easily adapted to fit the 3 DoF case. The first main difference in the procedure is the need to collect only 2D Cartesian points of the AMR-CT in each coordinate system (i.e.,{OTS}v⃗j and{MAP_2D}v⃗j) and at level locations throughout the environment. Since the two vectors are assumed to track approximately the same point, a solution to the absolute orientation problem,{OTS}ξ{MAP_2D}{MAP_2D}v⃗j ≈{OTS}⃗vj, is applied. Therefore, the complete coordinate system transformation chain for the 3 DoF case is expressed by Eq.6. Note that, since{OTS}ξ{MAP_3D},{MAP_2D}ξ{MAP_3D}, and{OTS}ξ{MAP_2D}are measured based on samples of a tracked point associated with the AMR-CT base, these transfor- mations (or their respective inverses) are directly applicable only to AMR-CT poses expressed in either the MAP_2D, MAP_3D, or OTS coordinate frames. Referring again to FIG.2, first, the event-based AMR-CT control loop 210 (see, also, FIG.3) provides coarse posing (navigation) of the mobile manipulator to a goal near the CMMA using the OTS. If the goal was successfully reached, then the second control loop 220 (see, also, FIG.4) proceeds, which provides refined docking of the AMR-CT close to the CMMA such that the manipulator could reach the CMMA. If the CMMA were to be moved during this process, control would return back to the coarse pose AMR-CT control loop, otherwise the control flow proceeds upon successful docking. Finally, the closed-loop manipulator control algorithm 230 and data flow using Cartesian / linear servo pose commands are described and shown with respect to FIG.5, which poses the manipulator EOAT over the assembly fiduciaries to simulate mock peg-in-hole assembly. Note that an alternative design, which uses a PID controller and tool-center-point (TCP) control via velocity-based commands is also possible and may be desirable in case the Cartesian / linear servo pose controller exhibited limitations in responsiveness. Before describing each control algorithm individually, the steps common to all three controllers are now addressed. First, the poses for the needed rigid bodies (i.e., the CART, EOAT, and CMMA rigid bodies for the Cartesian pose controller, just the EOAT and CMMA rigid bodies for the velocity controller, and just the CMMA rigid body for the AMR-CT control algorithm) are streamed over user datagram protocol from the OTS to the system on module (SoM) mounted on the cart using the manufacturer software development kit. The poses arrive at the SoM in vector- quaternion pair format. The OTS may be configured to stream data at 125 FPS. The data streaming client, running on the SoM then receives the data and pre-processes it to verify that no significant occlusions, dropped packets, or mislabeling occurs. If a network or data quality error occurs, the client would wait until clean data arrives. Otherwise, the controllers proceed to the next processing steps. The dead-reckoning move command is needed to dock the AMR-CT close to the CMMA without detecting it as an obstacle and the deltaHeading command is used to implement heading corrections. As such, two control loops are needed for AMR-CT control: the first control loop coarsely poses the AMR-CT 1 m away from the intended docking position, while the second control loop allows the AMR-CT to dock close to the CMMA while simultaneously correcting the AMR-CT heading. The former control loop is detailed first. Referring now to FIG.3, after receiving the marker position data from the OTS and computing the needed rigid body poses, the AMR-CT controller executes the following steps. First,{cbase}ξ{dock} is computed using Eq.2, vector-quaternion pose composition, and quaternion inverses where applicable. The controller uses this transformation, which represents the error between the current pose of the manipulator cart base and the docking goal, to check if the AMR-CT had arrived at the docking goal near the CMMA. Additionally, the speed of manipulator cart base and the change in pose of the CMMA between the current loop execution and the preceding loop execution (denoted monitored. If the error between manipulator cart base pose and docking goal is greater than a pre-set threshold (e.g., ±200 mm in position and ±0.035 rad in heading based on the specs of the AMR-CT), and the velocity of manipulator cart base (e.g., 1mm / s) and{cmma}⃗δ is less than another pre-defined threshold (e.g., ±5 mm), then the controller would do nothing. However, if the error between manipulator cart base pose and docking goal, the velocity of manipulator cart base, and{cmma}δ⃗all falls below their respective pre- set thresholds, then the control loop would end, a stop command would be sent to the vehicle through the clear-text API, and control would be handed over to the manipulator. Otherwise, the control loop continues and updates the commanded pose of the AMR-CT based on the updated CMMA pose. This step is completed using either Eq.6 or Eq.5 (again using vector-quaternion pose composition, and quaternion inverses where applicable) depending on whether 3 DoF or 6 DoF are used for the registrations. The pose containing the new commanded AMR-CT pose,{MAP_2D}ξ{vbase}is then converted to a vector format consisting of Cartesian position components and a heading. The vector components could then be directly substituted as input parameters for a doTask goToPoint clear-text command, which updates the AMR-CT path planning with a new goal. As the vehicle travels to the new goal, the pose of the manipulator cart base relative to the CMMA, (i.e.,{cmma}ξ{cbase}) would change and the control loop repeats. Referring now to FIG.4, the second control loop is now described. The steps to acquire{cbase}ξ{dock} are identical to the preceding control loop. From this transformation, the relative yaw angle between manipulator cart base and the CMMA is extracted. If the heading error is greater than a preset threshold, then a heading correction is applied to the vehicle using a deltaHeading command to turn the AMR- CT in the direction opposite to the error. The deltaHeading command would be allowed to execute until the heading error fell below the error threshold. After the heading constraint has been satisfied, if the distance between manipulator cart base and CMMA is greater than another preset threshold, then the AMR-CT would be commanded to move forward to dock with the CMMA. The move command would be allowed to run until manipulator cart base reaches the desired docking position. Note that control could shift between docking and correcting the heading at any time as needed. When both the heading and distance constraints have been satisfied, the control loop would terminate successfully. However, another termination condition is included: If, at any time, the CMMA is moved, then the docking control loop termi- nates and control is returned to the coarse pose control loop described above. The control loop steps to pose the manipulator EOAT such that the assembly fiduciary is intercepted by the RLS is now described. After the common steps outlined above, the manipulator pose controller that used Cartesian / linear servo commands then computes the needed relative poses. Specifically, these poses are{eoat}ξ{a fi} (using Eq.4),{cbase}ξ{eoat}(using Eq.3) and{cbase}ξ{a fi} (using Eq.1). The Cartesian / linear servo controller then checks the error between the EOAT and its commanded pose. The translation error is computed as the Euclidean norm of the translational component of{eoat}ξ{a fi} and the orientation error is computed as φ3 = arccos(|{cbase}q{eoat} ·{cbase}q{a fi}|) where q is the quaternion representation of the respective relative poses. Note that φ3 mapped to an angle between 0 andπ / 2rad. A slightly different metric, φ4 = |{cbase}q{eoat}·{cbase}q{a fi}|, could be used instead to further improve computational efficiency. If the error is less than a pre-defined threshold (e.g., between 1 mm and 5 mm distance for the translation and ±0.0209 rad for the orientation) or the commanded pose of the EOAT exceeds the 850 mm reach of the manipulator, then the control loop is terminated and either the “stopL()” or “servoStop()” API call is made. For both API calls, a stopl script command is forwarded to the manipulator. If the control loop terminates for the former reason, then the arm has successfully reached the commanded pose, and, as has been done in the past, a spiral search trajectory is traced by the EOAT using open-loop control to verify how much, if any, error exists between the commanded EOAT pose and the actual location of the assembly fiduciary. However, if the control loop terminates for the latter reason, control is returned to the AMR-CT so that the manipulator can be re-docked within reachable distance of the CMMA. Otherwise, the closed manipulator control loop proceeds and the pose,{cbase}ξ{a fi}, is converted to an alternative vector format containing the Cartesian position components and orientation components as a rotation vector. The components of this vector are directly passed as arguments to the ur_rtde library, which has API calls, “moveL()”, which directly corresponds to a movel script command on the manipulator controller, and “servoL()”, which corresponds to a get_inverse_kin command followed by a servoj command on the manipulator controller. The manipulator controller is expected to be able to execute these commands at a frequency of no greater than 125 Hz, and for the “servoL()” API call, the look-ahead time and proportional gain parameters should to be tuned in a fashion similar to that of the PID controller gains used in the velocity controller. This results in the arm being actuated, which changes the pose of the EOAT relative to the CMMA (i.e.,{cmma}ξ{eoat}). The OTS would then observe the new pose and the control loop repeated until the error fell below the threshold. One key problem encountered while integrating conventional software and registration algorithms may include coordinate system transformation inconsistencies. This problem may require the calibration of replacement coordinate system transformations to suit newly integrated hardware and software. Disclosed herein, then, are calibration procedures in accordance with the invention. Robot Operating System packages for implementing robot map management, localization, navigation, and planning may be used. With these packages it is possible to arbitrarily place the origin of the autonomous mobile robot map coordinate system such that it matches the placement of an OTS coordinate system. However, with exemplary AMR-CTs there may be no known way to precisely specify the map coordinate system origin upon creating a new laser scan of the environment or re-position the map coordinate system origin after map creation. Therefore, a first calibration problem may include determining the transformation between the AMR- CT map coordinate system origin and the OTS coordinate system. In conventional methods, calibrations may assume a relatively fat, level floor surface in the environment space such that problems and solutions can be simplified to use 2D projections. However, floor leveling may not be consistently fat across the environment, so, a full 6DoF calibration may be used in exemplary systems, representing an improvement over conventional methods. FIG.12 shows the coordinate systems involved in the calibration problem. First, the variable, vbase, is used to denote the local coordinate frame placed at the base centroid of the AMR-CT. This coordinate system is observed relative to three other coordinate frames that include the OTS (denoted OTS), the origin of the 2D map coordinate system used by the AMR-CT controller for navigation (denoted MAP_2D), and the origin corresponding to a 3D projection of the 2D map coordinate system used by the AMR-CT controller (denoted MAP_3D). Therefore, the 6DoF homogeneous transformation matrix,{MAP_2D}Hi{vbase}, represents the i-th (out of n total) observed pose of the AMR-CT base relative to the MAP_2D coordinate system. Similarly, the matrices{MAP_3D}Hi{vbase} and{OTS}Hi{vbase} represent i-th (out of n total) observed pose of the AMR-CT base relative to the MAP_3D and OTS coordinate systems, respectively. Additionally, let{MAP_2D}H{vbase} = [{MAP_3D}H1{vbase}, matrices containing all n observations in each coordinate system). The aforementioned homogeneous transformation matrices constitute the known coordinate transformations of the calibration problem and may be constructed from experimental data obtained from the AMR-CT controller, two digital levels, and the rigid body tracking of the OTS. The problem of measuring the transformation between the AMR-CT map coordinate system origin and the OTS coordinate system amounts to using the known homogeneous transformation matrices just described to solve for two unknown homogeneous transformation matrices: the transformation of the MAP_2D coordinate system relative to the MAP_3D coordinate system (denoted{MAP_2D}H{MAP_3D}) and the transformation of the MAP_3D coordinate system relative to the OTS coordinate system{MAP_3D}H{OTS}. Solving for the two unknown homogeneous transformation matrices is accomplished by solving the two least squares optimization sub-problems presented in Eq.7 and Eq.8, which can be solved via conventional closed-form solutions. Note that, in Eq.7 and 8, ||.|| denotes the Frobenius norm. Two digital levels, either integral to the system, or external and, for example, mounted to the base of the AMR-CT are used in exemplary methods. Additionally, the calibration of each level may be checked and re-calibrated as needed before each use and following the manufacturer-specified procedure. The digital levels are used to identify seven distinct stops at which the AMR-CT is level (i.e., where both levels have a reading below a predetermined threshold, e.g., of ±0.25° or less) by driving (e.g., manually, via joystick) the AMR-CT throughout the environment and observing the digital level readings. Along with an assigned integer label (1-7), the approximate location and orientation of the stops may then be visually marked on the floor, e.g., using tape and permanent marker. The integer labels and a formula may be used to generate three random run-sequences among the stops, such that the measurements could be repeated three times per stop. The OTS may be re-calibrated according to the manufacturer-specified procedure. The AMR-CT localization may be verified prior to measurement by sending the AMR-CT to the “LDStart” goal and observing the localization score in the manufacturer software. The measurement procedure is as follows. For each stop in the randomly generated sequence, the operator would move the AMR-CT to a known level location, e.g., the stop position marked by the tape on the floor. The operator then monitors the digital levels and adjusts the AMR-CT pose until both digital levels had readings of less than a predetermined threshold, e.g., ±0.02°. Note that, due to this, the AMR-CT pose at each stop could vary between repetitions, but having a variety of poses has been determined to be beneficial for the measurement procedure. The signed values of the digital levels, the AMR-CT pose (including x, y, θ components as read from the manufacturing monitoring software) in the map coordinate system, and the AMR-CT localization score, which is a measure of confidence based on the percentage of laser readings the AMR-CT receives that matches the scans in its current map, are then recorded. The operator then records the OTS tracking data of the static “VEHICLE BASE” rigid body for a predetermined interval, e.g., 10 seconds. This process is repeated, e.g., for each of the seven stops in the sequence and for three repetitions per stop (a total of n = 21 observations). Next, data cleaning may occur. For example, the Cartesian position and quaternion rotation of the “VEHICLE BASE” rigid body centroid and the Cartesian positions of each marker may be aggregated across all frames for each capture by computing the component-wise average, and the markers for the first file may be plotted to verify marker labels. The component-wise average of the rigid body quaternion rotation may then be normalized to approximate the average rigid body orientation. Additionally, the component-wise standard deviation for each marker across all data captures may be computed (and, if desirable, displayed in box plots or the like). Next, a plot of the individual markers for the VEHICLE_BASE rigid body for one data capture may be generated to verify the rigid body marker positions and labels. While the data captures include the Cartesian position and quaternion orientation of the rigid body centroid as defined in the OTS software, the placement of this centroid is not guaranteed to align with the physical centroid of the AMR-CT base because it is determined by the (in this case asymmetrical) placement of the individual markers. Therefore, the Cartesian position (with components along the x, y, and z) axes of the physical AMR-CT base centroid in the OTS coordinate system is estimated as the midpoint of two or more markers for each data capture. The corresponding rotation of the AMR-CT base in the OTS coordinate system is estimated for each data capture using the normalized, component-wise average of the VEHICLE_BASE rigid body centroid quaternion orientation. This information may be used to populate each homogeneous transformation matrix,{OTS}Hi{vbase}, for all (e.g., n = 21) OTS data captures. The AMR-CT map data pre-processing is now described, which mainly consists of changing the pose representation such that each{MAP_2D}Hi{vbase} and{MAP-_3D}Hi{vbase}could be populated for all (e.g., n = 21) poses recorded from the AMR-CT controller. Since the poses obtained in the MAP_2D coordinate frame had 3DoF (i.e., the positional x and y components, as well as the θ heading component), the poses were embedded into the 6DoF{MAP_2D}Hi{vbase} homogeneous transformation matrices by setting the height positional component, as well as the roll and pitch angles of the orientation to zero for each transform. Then, to form the{MAP_3D}Hi{vbase} homogeneous transformations (i.e., the{MAP_2D}Hi{vbase} transformations projected into 3D), OTS data is used instead to initialize the height component and the digital levels readings may be substituted for the roll and pitch angles of the orientation. Specifically, for the height component, the first transformation still assumes the height to be zero, but for subsequent transforms the script computes and substitutes the difference in height between the first measured pose and the current pose being processed based on the corresponding estimated AMR-CT centroid data obtained from the OTS. The pre-processed data samples serve as input to a script that reads in the pre-processed pose data and applies code written to solve the 6DoF and 3DoF calibration sub-problems expressed by Eq.7 and 8 using the appropriate closed- form solution. The final, measured coordinate system transformations were: . However, it should be noted that an additional constant rotation of −90° was also applied when using these transformations prior to publishing AMR-CT poses in the / ld_arcl_outgoing node. This may be done when the primary direction of travel for the AMR is along the y axis instead of along the x axis. It should be understood that the calculations and processes described herein may be performed by any suitable computer system, such as that diagrammatically shown in FIG.13. Data is entered into system 1300 via any suitable type of user interface 1316, and may be stored in memory 1312, which may be any suitable type of computer readable and programmable memory and is preferably a non-transitory, computer readable storage medium. Calculations are performed by processor 1314, which may be any suitable type of computer processor and may be displayed to the user on display 1318, which may be any suitable type of computer display. Processor 1314 may be associated with, or incorporated into, any suitable type of computing device, for example, a personal computer or a programmable logic controller. The display 1318, the processor 1314, the memory 1312 and any associated computer readable recording media are in communication with one another by any suitable type of data bus, as is well known in the art. Examples of computer-readable recording media include non-transitory storage media, a magnetic recording apparatus, an optical disk, a magneto-optical disk, and / or a semiconductor memory (for example, RAM, ROM, etc.). Examples of magnetic recording apparatus that may be used in addition to memory 1312, or in place of memory 1312, include a hard disk device (HDD), a flexible disk (FD), and a magnetic tape (MT). Examples of the optical disk include a DVD (Digital Versatile Disc), a DVD-RAM, a CD-ROM (Compact Disc-Read Only Memory), and a CD-R (Recordable) / RW. It should be understood that non-transitory computer-readable media include all computer-readable media except for a transitory, propagating signal. The processes described herein may be embodied in, and fully automated via, software code modules executed by a computing system that includes one or more general purpose computers or processors. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all the methods may alternatively be embodied in specialized computer hardware. In addition, the components referred to herein may be implemented in hardware, software, firmware, or a combination thereof. Many other variations than those described herein will be apparent from this disclosure. For example, depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithms). Moreover, in certain embodiments, acts or events can be performed concurrently, e.g., through multi- threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. In addition, different tasks or processes can be performed by different machines and / or computing systems that can function together. Any logical blocks, modules, and algorithm elements described or used in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and elements have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure. The various illustrative logical blocks and modules described or used in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a processing unit or processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor includes an FPGA or other programmable device that performs logic operations without processing computer- executable instructions. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor may also include primarily analog components. For example, some or all of the signal processing algorithms described herein may be implemented in analog circuitry or mixed analog and digital circuitry. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few. The elements of a method, process, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module stored in one or more memory devices and executed by one or more processors, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of non- transitory computer-readable storage medium, media, or physical computer storage known in the art. An example storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The storage medium can be volatile or nonvolatile. While one or more embodiments have been shown and described, modifications and substitutions may be made thereto without departing from the spirit and scope of the invention. Accordingly, it is to be understood that the present invention has been described by way of illustrations and not limitation. Embodiments herein can be used independently or can be combined. All ranges disclosed herein are inclusive of the endpoints, and the endpoints are independently combinable with each other. The ranges are continuous and thus contain every value and subset thereof in the range. Unless otherwise stated or contextually inapplicable, all percentages, when expressing a quantity, are weight percentages. The suffix (s) as used herein is intended to include both the singular and the plural of the term that it modifies, thereby including at least one of that term (e.g., the colorant(s) includes at least one colorants). Option, optional, or optionally means that the subsequently described event or circumstance can or cannot occur, and that the description includes instances where the event occurs and instances where it does not. As used herein, combination is inclusive of blends, mixtures, alloys, reaction products, collection of elements, and the like. As used herein, a combination thereof refers to a combination comprising at least one of the named constituents, components, compounds, or elements, optionally together with one or more of the same class of constituents, components, compounds, or elements. All references are incorporated herein by reference. The use of the terms “a,” “an,” and “the” and similar referents in the context of describing the invention (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. It can further be noted that the terms first, second, primary, secondary, and the like herein do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. It will also be understood that, although the terms first, second, etc. are, in some instances, used herein to describe various elements, these elements should not be limited by these terms. For example, a first current could be termed a second current, and, similarly, a second current could be termed a first current, without departing from the scope of the various described embodiments. The first current and the second current are both currents, but they are not the same condition unless explicitly stated as such. The modifier about used in connection with a quantity is inclusive of the stated value and has the meaning dictated by the context (e.g., it includes the degree of error associated with measurement of the particular quantity). The conjunction or is used to link objects of a list or alternatives and is not disjunctive; rather the elements can be used separately or can be combined together under appropriate circumstances. Although the invention has been shown and described with respect to a certain embodiment or embodiments, it is obvious that equivalent alterations and modifications will occur to others skilled in the art upon the reading and understanding of this specification and the annexed drawings. In particular regard to the various functions performed by the above described elements (components, assemblies, devices, compositions, etc.), the terms (including a reference to a "means") used to describe such elements are intended to correspond, unless otherwise indicated, to any element which performs the specified function of the described element (i.e., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary embodiment or embodiments of the invention. In addition, while a particular feature of the invention may have been described above with respect to only one or more of several illustrated embodiments, such feature may be combined with one or more other features of the other embodiments, as may be desired and advantageous for any given or particular application.

Claims

Claims What is claimed is:

1. An agitator for controllably agitating a workstation and / or workpiece comprising: a base practically immobile with respect to a global reference frame; an actuator mounted to the base; a controller configured to agitate the actuator; and a sensor configured to sense a position of a distal end of the actuator.

2. The agitator of any preceding claim, wherein the base includes removable weight configured to, while attached, weigh the base down, making the base practically immobile and, while removed, allow the base to be practically moveable.

3. The agitator of any preceding claim, wherein the controller is a system- on-board computer outfitted with two four-channel relay boards.

4. The agitator of any preceding claim, wherein the actuator is a linear actuator.

5. The agitator of any preceding claim, wherein the distal end of the actuator is rotatably coupled to a workstation and a proximal end of the actuator is rotatably coupled to the base.

6. The agitator of any preceding claim, wherein the sensor includes a linear encoder.

7. The agitator of any preceding claim, wherein the sensor includes a string encoder or potentiometer.

8. The agitator of any preceding claim, wherein the sensor is a ground truth reference sensor.

9. The agitator of claim 8, wherein the ground truth reference sensor includes a plurality of optical tracking system registers at a distal end of the actuator for optically tracking movement of the actuator with respect to the global reference frame.

Images