Transport Device and Control System

Abstract

A transfer device, such as a patient transfer device, includes a device body, a transfer platform supported by the device body, a plurality of subsystems, a plurality of subsystem controllers, each configured to control the operation of one of the plurality of subsystems, and a system processor in communication with the plurality of subsystem controllers. The transfer platform has at least one conveyor belt configured to move objects. Each subsystem is configured to perform a function of the transfer device. The system processor is configured to monitor the plurality of subsystem controllers, communicate with the plurality of subsystem controllers, receive operator input from a transfer device operator, make decisions regarding transfer operations based on inputs received from the transfer device operator and / or inputs received from the plurality of subsystem controllers, and send commands to the plurality of subsystem controllers to accomplish various transfer operation routines.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 63 / 362,301, filed March 31, 2022, entitled “Distributed Control System for a Transfer Device,” which is hereby incorporated by reference in its entirety.

[0002] FIELD OF THE DISCLOSURE The present disclosure relates generally to transport devices for moving objects, and more particularly to control systems and methods for such transport devices. [Background technology]

[0003] A transfer device generally has a device body and a transfer platform configured to move an object. The transfer device can be controlled by a control system to control the movement of the transfer platform, for example, when moving an object or a patient.

[0004] According to conventional approaches, control systems used for transport devices may have several drawbacks: (i) they may be expensive, (ii) they may involve various design compromises, (iii) they may lack modularity, scalability, and adaptability, and (iv) they may suffer from poor signal management and consistency.

[0005] Furthermore, the control system may have limited automation and control capabilities, thereby relying on manual user control and intervention. Unfortunately, this manual user control and intervention can be cumbersome and can result in difficulties such as variability in user interaction and interpretation. In situations where objects are fragile or delicate, especially when transferring patients who may be infirm and / or immobile, erroneous inputs and control commands from the user can result in serious harm or damage to the patient or object being transferred.

[0006] Thus, the conventional approaches leave much to be desired. It is an object of the disclosed technology to improve upon the conventional approaches to address or mitigate some or all of the above-mentioned shortcomings. Summary of the Invention

[0007] The disclosed technology provides a transfer device for moving an object, as well as related control systems, devices, and methods. One aspect of the disclosed technology includes a transfer device having a control system. In various implementations, the transfer device is configured to move a patient, and thus may be referred to as a patient transfer device in some cases. A transfer device according to various implementations may have architectural variations, but generally includes a body having an actuator, a transfer platform, and a conveyor belt or conveyor belts operatively configured to move an object, such as a patient. In some cases, various components and / or functions of the transfer device may be considered to be part of one or more operational subsystems of the transfer device.

[0008] The control system has a system processor that maintains oversight of multiple subsystem controllers that communicate with the system processor. In some cases, the control system is referred to as a distributed control system because control of the transport device is distributed between the system processor and the multiple subsystem controllers. Each subsystem controller is configured to communicate with and / or control various components to perform one or more functions of the transport device. In some cases, a subsystem controller can be considered to be part of and / or controlling one of the operational subsystems of the transport device.

[0009] The system processor is configured to perform various activities depending on the state of the transport device and the desired mode of operation. In some instances, the system processor is configured to monitor and communicate with one or more subsystem controllers. According to various implementations, the system processor is configured to perform certain operations or actions by loading and executing instructions stored in one or more memory devices. The system processor executing the instructions causes the control system and / or the transport device to perform the desired action.

[0010] According to various implementations, the system processor is configured with instructions, including preloaded, adaptable, interactive subroutines and algorithms. In some cases, the instructions configure the system processor to perform actions based on information collected or transmitted from the subsystem controller. For simplicity and convenience, the system processor is sometimes described as performing various actions. Such references include the meaning that the system processor is configured with appropriate instructions for execution by the system processor. In addition, the term "manager system" is used herein to refer to the system processor and various instructions stored in memory and / or the system processor configured to operate according to the various instructions (e.g., a collection of software applications running on the system processor) and therefore perform the corresponding activities.

[0011] Compared to using a single microcontroller, utilizing multiple subsystem controllers can result in reduced costs, avoidance of design compromises, and increased modularity, which in turn can enable scalability and adaptability. Also, in various implementations, one or more of the subsystem controllers can be located in different areas of the transport device (e.g., not all in a single location), thus providing a physically distributed control system. Such an arrangement can allow various subsystem controllers to be near specific sensors and / or actuators, allowing signals to be transmitted and received over shorter distances, which can improve signal integrity and reduce noise.

[0012] Various implementations of the distributed control system disclosed herein enable automatic and semi-autonomous operation. In such cases, various subsystem controllers can work together to automatically perform patient transfer without user intervention. The distributed control system can include various subsystem controllers depending on the implementation. In various cases, the distributed control system has a system processor configured with instructions to implement an abstracted operating system and a transport program that serves the purpose of collecting, interpreting, and sending commands on behalf of a human operator (also referred to herein as a "user"). In such cases, the manager system (i.e., the system processor programmed with specific instructions) can be configured to autonomously make decisions and send commands based on information received from the operator as well as one or more subsystem controllers. The subsystem controllers can include, but are not limited to, a power system controller, a transport operation controller (e.g., at least operating the platform and conveyor belt), and a lift and tilt actuator controller. It should be understood that additional proximity sensors and / or peripheral devices can also be included in typical configurations of such transport devices and control systems.

[0013] Various implementations of the disclosed technology include a transfer device and / or distributed control system having one or more of the following aspects and / or features. In some implementations, the manager system is configured to perform various operations based on operator input of transfer parameters (e.g., object or patient characteristics, such as, for example, height and body mass index). Other inputs may include parameters for the support surface (e.g., bed), such as width and type of mattress (e.g., air mattress or foam mattress). In various cases, the manager system may execute routines that enable cooperative operation of multiple subsystem controllers, such as, for example, coordination and unification of operating conditions. In some cases, the manager system may execute protection and safety routines to identify and communicate device-wide errors or failures to the necessary subsystem controllers, thereby enabling the subsystem controllers to execute corresponding actions, such as, for example, shutting down the motor. In some cases, the manager system may centralize various device-level subroutines. As an example, the manager system may execute security for the transfer device, including preventing unauthorized access and / or inappropriate commands from being sent directly to the subsystem controllers in the event of a security breach (e.g., a hacking event).

[0014] Also disclosed is a method of operating a transport device. In various implementations, the transport device has a device body, a transport platform, at least one conveyor belt, and a distributed control system including a manager system and a number of subsystem controllers. The manager system includes a system processor and executable instructions stored on a physical non-transitory medium that cause the system processor to relay information to the subsystem controllers, record and transmit acquired information, and send actions and / or requests to the subsystem controllers in the distributed control system.

[0015] According to various aspects, another method of operating a transfer device includes receiving one or more images from at least one imaging device and processing the image(s) to determine at least one variable associated with the transfer of an object by the transfer device.

[0016] Also disclosed is a non-transitory computer-readable medium having recorded thereon statements and instructions that, when executed by a system processor of a transport device, configure the system processor to implement one or more of the various systems and methods disclosed herein.

[0017] Examples of various implementations of the disclosed technology include, but are not limited to, the following.

[0018] In Example 1, a transfer device includes a device body, a transfer platform supported by the device body, the transfer platform comprising at least one conveyor belt configured to move objects onto and / or off the transfer platform, a plurality of subsystems, each configured to perform a function of the transfer device, a plurality of subsystem controllers, each subsystem controller configured to control operation of one of the plurality of subsystems, and a system processor in communication with the plurality of subsystem controllers, the system processor configured to monitor the plurality of subsystem controllers, communicate with the plurality of subsystem controllers, receive operator input from a transfer device operator, make decisions regarding transfer operations based on the input received from the transfer device operator and the input received from the plurality of subsystem controllers, and send commands to the plurality of subsystem controllers.

[0019] In example 2, the transport device of example 1, wherein two or more of the plurality of subsystem controllers are located in different regions of the transport device near one or more sensors and / or actuators.

[0020] In Example 3, the transfer device of Example 1 or 2, wherein the system processor and the multiple subsystem controllers are configured to operate together to automatically perform patient transfer without user intervention.

[0021] In Example 4, the transfer device of any one of Examples 1 to 3, wherein the system processor is configured to control a human machine interface (HMI) of the transfer device.

[0022] In Example 5, the transfer device of any one of Examples 1 to 4, wherein the plurality of subsystem controllers includes a subsystem controller configured to control the transfer of the object.

[0023] In Example 6, the transport device described in Example 5, wherein the distributed control system is configured to receive tension and displacement of at least one conveyor belt along with a location and speed of the transport platform for use in the method of transporting a patient.

[0024] In Example 7, the multiple subsystem controllers include a subsystem controller configured to adjust the height and angle of the transfer platform and / or transport of the transfer device, a transfer device described in any one of Examples 1 to 6.

[0025] In Example 8, the multiple subsystem controllers include a subsystem controller configured to control one or more peripheral subsystems of the transport device that are not involved in the movement of the transport platform. The transport device described in any one of Examples 1 to 7.

[0026] In Example 9, the transport device described in any one of Examples 1 to 8, wherein the plurality of subsystem controllers includes a subsystem controller configured to control the supply of power to electronic components of the distributed control system and to actuators of the transport device.

[0027] In Example 10, a transfer device described in any one of Examples 1 to 9, wherein the multiple subsystems are configured to perform one or more of: (i) transferring objects; (ii) adjusting the height and angle of the transfer platform and / or transporting the transfer device; (iii) controlling peripheral devices of the transfer device that are not involved in the movement of the transfer platform; (iv) providing device security; and (v) controlling power supply to electronic components of the distributed control system and to actuators of the transfer device.

[0028] In Example 11, a transport device described in any one of Examples 1 to 10, wherein the system processor is configured to establish a secure connection to an external network to upload captured images, diagnostic data, and / or download firmware changes.

[0029] In Example 12, the transport device of Example 11, wherein the external network is an intranet configured to support communication between multiple transport devices.

[0030] In Example 13, the transport device of Example 11, wherein the external network is the World Wide Web.

[0031] In Example 14, a transport device described in any one of Examples 1 to 13, wherein the system processor is in communication with an imaging subsystem having at least one imaging device, and the system processor is configured to receive at least one captured image from the at least one imaging device and determine at least one variable using image processing of the captured image, such that the at least one variable is related to the transport of an object by the transport device.

[0032] In Example 15, a transfer device as described in Example 14, wherein the system processor is configured to receive a plurality of captured images forming a video feed from at least one imaging device and determine at least one variable using image processing of the video feed, such that the at least one variable is related to the transfer of an object by the transfer device.

[0033] In Example 16, a transfer device as described in Example 14 or 15, wherein the subsystem controller is configured to determine at least one variable using processing of at least one captured image, such that the at least one variable is related to the transfer of an object by the transfer device.

[0034] In Example 17, the transfer device of Example 16, wherein the at least one variable includes a mass and / or a volume of the object.

[0035] In Example 18, the transfer device of Example 16 or 17, wherein at least one variable includes a position and / or orientation of the object.

[0036] In Example 19, a transfer device described in any one of Examples 16 to 18, wherein the system processor is configured to assess a risk of damage to the object based on at least one variable.

[0037] In Example 20, a transfer device described in any one of Examples 16 to 19, wherein the system processor is configured to determine parameters and / or limitations for the transfer device to transfer objects based on at least one variable.

[0038] In Example 21, a transfer device as described in Example 20, wherein the system processor receives feedback from at least one of the subsystem controllers regarding forces measured during transfer of the object, and the system processor is configured to adjust parameters and / or limits according to the feedback.

[0039] In Example 22, a transport device described in any one of Examples 16 to 21, wherein the system processor is connected to a persistent memory configured to record a video feed or an image feed for future playback.

[0040] In Example 23, a transport device described in any one of Examples 16 to 21, wherein the system processor is configured to establish an external data connection and to transmit an image feed or a video feed to an external receiving unit via the external data connection for monitoring and observation.

[0041] In Example 24, a method for execution by a system processor of a transfer device, the transfer device comprising a device body and a transfer platform configured to move an object, the method including receiving at least one image from at least one imaging device, and determining at least one variable using image processing of the at least one image, such that the at least one variable is related to the transfer of the object by the transfer device.

[0042] In Example 25, the method of Example 24, wherein the at least one variable includes a mass and / or a volume of the object.

[0043] In Example 26, the method of Example 24 or 25, wherein at least one variable includes a position and / or orientation of the object.

[0044] In Example 27, the method of any one of Examples 24 to 26, further comprising assessing a risk of damage to the object based on at least one variable that has been determined.

[0045] In Example 28, the method described in any one of Examples 24 to 27, further comprising determining parameters and / or limitations for the transport device to transport the object based on at least one variable that has been determined.

[0046] In Example 29, the method of Example 28, further comprising receiving feedback regarding forces measured during transport of the object, and adjusting parameters and / or limits according to the feedback.

[0047] In Example 30, the method of any one of Examples 24-29, further comprising recording at least one image for future playback.

[0048] In Example 31, the method described in any one of Examples 24 to 30, further comprising establishing an external data connection and transmitting at least one image to an external receiving unit via the external data connection for monitoring and observation.

[0049] In Example 32, a non-transitory computer-readable medium having recorded thereon statements and instructions that, when executed by a system processor of a transfer device, configure the system processor to perform the method described in any one of Examples 24 to 31.

[0050] In Example 33, a device comprising any combination of components or components described and / or depicted herein.

[0051] In Example 34, a method comprising any combination of steps or steps described and / or depicted herein.

[0052] In Example 35, a non-transitory computer-readable medium having recorded thereon statements and instructions that, when executed by a processor of the device, configure the processor to perform a method including any step or combination of steps described and / or depicted herein.

[0053] Other aspects and features of the disclosed technology will become apparent to those of ordinary skill in the art upon review of the following description of various embodiments of the present disclosure.

[0054] The embodiments will be described with reference to the accompanying drawings. [Brief description of the drawings]

[0055] [Figure 1] 1 is a block diagram of a distributed control system for a transport device according to various implementations. [Figure 2A] 1A-1D are schematic diagrams of an exemplary transfer device, according to various implementations. [Figure 2B] 1A-1D are schematic diagrams of an exemplary transfer device, according to various implementations. [Figure 2C] 1A-1D are schematic diagrams of an exemplary transfer device, according to various implementations. [Figure 3A] 1 is a block diagram of a distributed control system for a transport device according to various implementations. [Figure 3B] 1 is a block diagram of a distributed control system for a transport device according to various implementations. [Figure 4A] 1A-1C are various diagrams of example user interface controls for a human machine interface (HMI) of a transport device, according to various implementations. [Figure 4B] 1A-1C are various diagrams of example user interface controls for a human machine interface (HMI) of a transport device, according to various implementations. [Figure 4C] 1A-1C are various diagrams of example user interface controls for a human machine interface (HMI) of a transport device, according to various implementations. [Figure 4D] 1A-1C are various diagrams of example user interface controls for a human machine interface (HMI) of a transport device, according to various implementations. [Figure 4E] 1A-1C are various diagrams of example user interface controls for a human machine interface (HMI) of a transport device, according to various implementations. [Figure 4F] 1A-1C are various diagrams of example user interface controls for a human machine interface (HMI) of a transport device, according to various implementations. [Figure 4G] 1A-1C are various diagrams of example user interface controls for a human machine interface (HMI) of a transport device, according to various implementations. [Figure 4H] 1A-1C are various diagrams of example user interface controls for a human machine interface (HMI) of a transport device, according to various implementations. [Figure 4I] 1A-1C are various diagrams of example user interface controls for a human machine interface (HMI) of a transport device, according to various implementations. [Figure 5A] 1 is a flow diagram of a method for transferring an object using a transfer device, according to various implementations. [Figure 5B] 1 is a flow diagram of a method for transferring an object using a transfer device including image processing, according to various implementations. [Figure 5C] 1 is a flow diagram of an image analysis method, according to various implementations. [Figure 5D] FIG. 1 is a flow diagram of a method for estimating patient mass and volume, according to various implementations. [Figure 5E] FIG. 1 is a flow diagram of a method for performing an image-based transportation risk assessment, according to various implementations. [Figure 5F]1 is a flow diagram of a method for relaying identified risks and other information to a user of a transport device according to various implementations. [Figure 6] 1A-1C are perspective views of a transport device having an imaging system according to various implementations. [Figure 7] 1 is a block diagram of a distributed control system for a transport device according to various implementations. [Figure 8A] 1 is a flow diagram of a method for aligning a transfer device, according to various implementations. [Figure 8B] 1 is a flow diagram of a method for detecting contact between a device transfer platform and a support surface, according to various implementations. [Figure 8C] 1 is a flow diagram of a method for determining a characteristic of a support surface, according to various implementations. [Figure 8D] FIG. 1 is a flow diagram of a method for detecting an obstacle, according to various implementations. [Figure 8E] 1 is a flow diagram of a method for adjusting a position of an object on a transport device, according to various implementations. [Figure 8F] 1A-1C are a series of diagrams illustrating different scenarios for adjusting the position of an object on a transport device, according to various implementations. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0056] First, illustrative implementations of one or more embodiments of the present disclosure are provided below, but it should be understood that the disclosed technology can be implemented using any number of techniques, whether currently known or in existence. The present disclosure is in no way limited to the illustrative implementations, drawings, and techniques illustrated herein, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims, along with the full scope of equivalents thereof.

[0057] As discussed above, aspects of the disclosed technology provide transfer devices, systems, and methods for moving objects, such as, for example, patients. As used herein and described with respect to the drawings, this aspect of the disclosure is often referred to as transfer device 200, patient transfer device 200, and variations thereof. Another aspect of the disclosed technology provides devices, systems, and methods for controlling transfer device 200. As used herein and described with respect to the drawings, this aspect of the disclosure is often referred to as control system 100, distributed control system 100, and variations thereof. It should be understood that the use of such terms to refer to these aspects of the disclosure is for brevity and convenience and is in no way intended to be limiting to any particular aspect.

[0058] According to various implementations, the architecture of the transport device can vary, but generally includes a body having an actuator, a transport platform, and a conveyor belt or belts operatively configured to move an object. In various implementations, the control system of the transport device includes a system processor in communication with multiple subsystem controllers. Each subsystem controller is configured to communicate with and / or control various components to perform one or more functions of the transport device. In some cases, the components and functions of the transport device can be considered to belong to one or more operational subsystems of the transport device. In such cases, one or more subsystem controllers can be considered to be part of and / or controlling one of the operational subsystems.

[0059] Referring initially to Figure 1, a block diagram of a distributed control system 100 for use with a transport device 200 according to various implementations of the disclosed technology is shown. The distributed control system 100 has a system processor 110 coupled to a number of subsystem controllers 120, depicted in Figure 1 as subsystem controllers 1 through N. Each subsystem controller 120 according to these implementations is configured to perform functions of the transport device 200, such as, for example, operation of a transfer sequence, control and monitoring of a power system, patient monitoring, movement of the transport device including lifting, tilting and / or transporting, and device security. The system processor 110 is configured to, among other things, monitor and communicate with the subsystem controllers 120.

[0060] According to various implementations, the system processor 110 includes or is coupled to one or more physical, non-transitory, computer-accessible or readable storage devices, also referred to herein as "memory" and "memory devices." Memory may be implemented using any suitable memory technology, which may include, for example, temporary and longer-term configurations, volatile and non-volatile configurations, and solid-state and / or other physical formats. Examples of possible memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), magnetic hard disk, optical disk, floppy disk, flash memory, electrically programmable memory (EPROM) and electrically erasable and programmable (EEPROM) forms of memory, as well as other forms known in the art.

[0061] The memory device(s) coupled to the system processor 110 contain instructions for configuring the system processor 110 to perform certain operations or actions by loading and executing the instructions. The system processor 110 executing the instructions causes the control system 100 and / or the transport device 200 to perform the desired actions. References herein to the system processor 110 performing various activities include the implication that the system processor 110 is configured with corresponding instructions for execution. As noted above, the term "manager system" is used herein for convenience to refer to the system processor 110 and the various instructions stored in memory and / or the system processor actively operating in accordance with the various instructions (e.g., a collection of software applications stored in memory and executed on the system processor).

[0062] In various implementations, the manager system collects and interprets information from user inputs and subsystem controllers 120 to perform analysis and calculations, make automated decisions, and subsequently coordinate and command actions for the subsystem controllers 120. In some implementations, the manager system collects information from subsystem controllers 120 and communicates that information to other subsystem controllers 120. In various implementations, the manager system monitors the status and performance of the subsystem controllers 120.

[0063] In certain implementations, one or more of the subsystem controllers 120 are located in different areas of the transport device (e.g., not all in a single location), thus providing a physically distributed control system. Such an arrangement can allow various subsystem controllers to be near various sensors and / or actuators, allowing signals to be transmitted and received over shorter distances, improving signal integrity and mitigating noise. As an example, a particular subsystem controller may in some cases be physically located in an area common to multiple components of a particular subsystem of the transport device. As another example, in some cases, a transport controller that controls the drive and non-drive wheel motors and sensors is located in the base of the transport device. This location of the controller in the base allows for reduced wiring between the upper and lower assemblies of the transport device. As another example, in some cases, a precision analog-to-digital conversion system controller is located near a load cell that is used to measure the transient forces on the lift actuators of the device. Such an arrangement is advantageous because the raw electrical signals of the load cells are very small voltages and highly susceptible to noise.

[0064] Thus, the disclosed implementations of distributed control system 100 differ from centralized control systems where processing is generally located in one area. As described below, configuring distributed control system 100 with multiple subsystem controllers 120 in a decentralized manner (e.g., with one, two, or more subsystem controllers 120 located in different portions of the transport device associated with various functions) can offer several potential advantages over utilizing a centralized control system in one area.

[0065] In various cases, a first potential benefit of utilizing multiple subsystem controllers 120 is reduced cost. Often, processors such as microcontroller units (MCUs) are limited in terms of the number of general purpose inputs / outputs (GPIOs) they have. While it may be possible for a single MCU to have enough GPIOs to handle all of the functions of the transport device 200, that single MCU is likely to be expensive. In various implementations, each subsystem controller 120 is focused on a function of the transport device. Thus, it is possible to reduce the cost of each subsystem controller 120 by having reduced performance specifications (e.g., fewer GPIOs) such that the total cost of all of the subsystem controllers 120 may be lower than the cost of a single MCU with enough GPIOs to handle all of the functions.

[0066] A second potential advantage of utilizing the subsystem controller 120 is, in various implementations, the avoidance of design compromises. Attempting to use a single MCU may result in various design compromises as a result of a limited number of GPIOs or other specifications. Various customizations or compromises to address the limited number of GPIOs or other specifications may cause difficulties. On the other hand, in various cases, the specifications of the subsystem controller 120 may be sufficient to avoid such design compromises. Furthermore, a single MCU architecture may also have a relatively higher application cycle execution time than a distributed control system if it is capable of managing many sensors and control inputs. For example, a distributed control system implementation may include multiple subsystem controllers 120 operating in cooperation, each subsystem controller 120 having a shorter application cycle execution time than a single MCU architecture. The subsystem controllers 120 may communicate as needed between the distributed control systems 100, thereby likely providing an overall improved responsiveness and agility when compared to a system based on a single MCU architecture.

[0067] In various implementations, a third potential advantage of utilizing subsystem controllers 120 is modularity, which in turn can enable scalability and adaptability. In various implementations, since each subsystem controller 120 is focused on a function and / or subsystem of the transport device 200, it is possible to add or remove a function and / or subsystem by adding or removing a subsystem controller associated with that function and / or subsystem. This can enable customization of the transport device 200 to upgrade or pare down one or more functions, for example, depending on customer requirements or budget. For example, if the transport MCU is to be improved, but the human interface is not improved, only the transport MCU is changed. Also, it is noted that revising or redesigning an existing controller can present a difficult challenge to address. In various implementations of the disclosed technology, additional and / or new functions can be added to the transport device 200 by allowing them to communicate with a common component, such as the system processor 110. Furthermore, in the case of repair or maintenance of a given function, the subsystem controller 120 associated with the given function can be replaced or replaced without affecting other functions, which can reduce downtime.

[0068] A fourth potential benefit of utilizing multiple subsystem controllers 120 is, in various cases, improved signal management and integrity. There are physical / electrical challenges associated with collecting, interpreting, and managing sensor signals and outputting command signals to actuators (e.g., motors, brakes, etc.). In various implementations, to allow signals to be transmitted and received over shorter distances, the subsystem controllers 120 may be distributed to be located in close proximity to the associated subsystems, sensors, and / or actuators, which may improve signal integrity and reduce noise. Signal integrity may also be improved by utilizing more specialized processors for specific subsystems, which may not be ideal for the rest of the system. For example, using a processor specialized in analog-to-digital conversion (ADC) for the sensor interface may provide high fidelity conversion. However, this ADC processor may have limited functional capabilities beyond this task, and therefore separation of conversion from future operations allows these signals to then be transmitted to another processor specialized in digital signal processing and analysis, or other operations that need to be performed, for example.

[0069] In some implementations, in addition to the potential advantages discussed above, the distributed control system 100 can increase the efficiency and effectiveness of the transport device 200, for example, by enabling autonomous and automatic operation of the transport device while ensuring patient and user safety. In some implementations, the distributed control system 100 reduces the likelihood that the distributed control system 100 will not fail, the transport device will not be compromised, and the patient will not be compromised, in the event of a fault or failure of a portion of the transport device.

[0070] In the implementation of FIG. 1, the subsystem controller 120 includes a first subsystem controller, a second subsystem controller, and a third subsystem controller. However, more generally, the subsystem controller 120 can include two or more subsystem controllers, up to a maximum of N subsystem controllers, as will be readily understood. In various cases, the number of subsystem controllers 120 depends on how many functions of the transport device 200 are present according to the particular implementation. In various cases, each subsystem controller 120 can be considered to be part of an operational subsystem and / or controlling an operational subsystem of the transport device 200. Various types of transport devices 200 can vary in terms of the various subsystems and associated functions present. Also, the same type of transport device 200 can also vary in terms of the various functions provided. For example, a subsystem or function can be enabled for a first transport device, but disabled for a second transport device, even if the first and second transport devices are of the same type. Thus, the modular nature of the subsystem controllers, functions, and subsystems means that in various cases, they can be selectively enabled or disabled.

[0071] It should be understood that the distributed control system 100 is applicable to any suitable transfer device 200 having a device body and a transfer platform capable of moving an object or patient. Such movement generally involves a change in the physical state of the object or patient. The change in physical state can include a change in location (e.g., moving the object or patient from one location to another) and / or a change in orientation (e.g., rotating the object or patient 90°). Thus, as used herein, a "patient transfer" performed by a transfer device does not necessarily mean that the patient must change location, specifically when the patient's orientation is transferred from a first orientation to a second orientation (e.g., rotated from left shoulder to stomach). In various implementations, the transfer platform can be conveyor-based in that the transfer platform comprises a conveyor belt. There are many possibilities. To illustrate this point, refer to FIGS. 2A-C, which are schematic diagrams of an exemplary transfer device 200 in which the distributed control system 100 can be implemented.

[0072] 2A shows one possible transport device 200 having a platform plate that is a transport platform 202, according to various implementations. The platform plate has bi-directional functionality (i.e., can move in both directions) for moving a patient 10 from a first location 20 on one side of the transport device 200 to a second location 30 on the other side of the transport device 200. The transport device 200 is conveyor-based in that the platform plate comprises a conveyor belt.

[0073] 2B shows another possible transfer device 200 according to various implementations. The transfer device has platform segments instead of platform plates, such that the platform segments are used to "build" the transfer platform 202. The transfer platform 202 similarly has bi-directional functionality for moving the patient 10 from a first location 20 on one side of the transfer device 200 to a second location 30 on the other side of the transfer device 200. The transfer device 200 is conveyor-based in that the transfer platform formed of the platform segments comprises a conveyor belt.

[0074] 2C illustrates another possible transport device 200 having a platform plate that does not have bidirectional functionality, according to various implementations. The platform plate is a transport platform 202, but can only be extended in one direction. The transport device 200 is conveyor-based in that the platform plate comprises a conveyor belt.

[0075] The transfer device 200 of Figures 2A-2C may be used to perform transfer of the patient 10 from an initial starting position on a surface onto the platform of the device and then transfer the patient 10 again onto the same or a different desired surface. For example, the articulating platform may be extended to a position below the patient 10 to be transferred, e.g., between the patient 10 and the surface on which the patient 10 is supported, and then retracted with the patient 10 supported by the transfer belt and transfer platform such that the patient 10 is positioned above the device body. Additionally or alternatively, the transfer platform may be extended to transfer the patient 10 positioned above the device body (i.e., supported on the transfer belt) onto a remote surface.

[0076] Although transport device 200 has been specifically described in connection with and in use for transporting human bodies (e.g., individuals with reduced, limited, or no mobility, healthy individuals, unconscious individuals, incapacitated individuals, etc.), it is understood that transport device 200 may alternatively be used to transport other objects, such as those that are bulky, cumbersome, delicate, and / or difficult to grasp and move. For example, transport device 200 may be suitable and / or adapted for use to transport livestock or captive animals, non-captive animals (e.g., in a zoo or wildlife rehabilitation facility), human remains (e.g., in a mortuary funeral home), inanimate objects (e.g., in courier, cargo, and / or logistics operations), and the like.

[0077] Transfer devices other than those shown in Figures 2A-2C are possible in various implementations. The implementation of the distributed control system 100 is applicable to any suitable transfer device 200 having a transfer platform 202 capable of moving an object, whether the transfer platform supports bidirectional or unidirectional functionality, and whether the transfer platform is implemented using plates, segments, and / or other components. Additional examples of suitable transfer devices 200 that may be adapted for use in accordance with the present disclosure are described in International Patent Application No. PCT / CA2022 / 050044, filed January 12, 2022, and published July 21, 2022 as WO2022 / 150915A1, entitled "Devices and Methods for Transferring an Object," which is incorporated herein by reference in its entirety.

[0078] Referring back to FIG. 1 , in some implementations, the system processor 110 is a central processing unit (CPU), although other processors are possible, such as, but not limited to, an MCU, a field programmable gate array (FPGA), and an application specific integrated circuit (ASIC). In some implementations, the system processor 110 includes a primary processor and a redundant processor that can be a backup in case of a failure by the primary processor. In various cases, the system processor 110 includes or is coupled to one or more memory devices that include instructions for configuring the system processor 110 to perform certain operations or actions. As discussed elsewhere, the configuration of the system processor 110 with various instructions provides, among other things, a manager system that can monitor and communicate with the subsystem controller 120. In some implementations, the manager system supports a human-machine interface in addition to monitoring and communicating with the subsystem controller 120.

[0079] According to various implementations, one or more of the subsystem controllers 120 are implemented with an MCU, although other processors are also possible, including but not limited to a CPU, FPGA, and ASIC. In various cases, the subsystem controller 120 also includes one or more memory devices included in and / or coupled with the processor. In such cases, the memory stores instructions that configure the processor to perform one or more tasks.

[0080] There are many possibilities for the various functions and / or subsystems handled by the subsystem controller 120. Examples include, but are not limited to, actuation and control of the transport platform and belts, a human machine interface 320 (HMI) for the transport device, lifting, tilting or other forms of positioning and location, transportation of the transport device, management and control of the transport device's peripherals, and power supply and management for the transport device. Further exemplary details are provided below with reference to the drawings. It should be noted that additional and alternative functionality is possible.

[0081] According to various implementations, the manager system can be configured to make decisions or execute pre-determined routines based on a combination of user input, external sensory input, and / or information obtained from the subsystem controllers. In such cases, the manager system automates various system and / or subsystem routines, thereby reducing the demands on the operator. Automated routines may include, for example, providing pre-loaded transfer routines to the operator or user, automatically enabling cleaning cycles, maintaining device-level authorization and defense security, or executing staging and device configuration routines before or immediately after a transfer is completed.

[0082] A potential advantage of such a manager system in various implementations would be to provide scalability of the manager system without having to modify code on one or more subsystem controllers. For example, multiple configuration and / or transport programs can be easily uploaded, adapted, and / or adjusted by technicians and / or operators to change the configuration and behavior of the device. This approach greatly simplifies the management and organization of coordinates, parameters, and other variables associated with the execution of a particular subroutine of a transport (e.g., a turn operation versus a transport operation).

[0083] 3A and 3B, an example of a distributed control system 100 is described according to various implementations. The distributed control system 100 may be implemented in any suitable transport device, such as the example transport device 200 shown in FIGS. 2A-2C. It should be understood that the example of the distributed control system 100 in FIGS. 3A and 3B is an exemplary implementation and is not intended to be limiting. Other variations of the distributed control system are possible and are within the scope of the present disclosure.

[0084] In these and other implementations, the distributed control system 100 includes a system processor 110 coupled to multiple subsystem controllers 120. The subsystem controllers 120 are configured to perform various functions of the transport device, as described in further detail below. In various implementations, the system processor 110 is configured to monitor and communicate with all of the subsystem controllers 120.

[0085] As shown in FIG. 3A, in some cases, the system processor 110 communicates with multiple subsystem controllers 120. The system processor 110 can be implemented by various hardware, software, and / or firmware in various cases. In some cases, the system processor 110 is configured with instructions to perform one or more activities and may be referred to as a manager system as previously described. The subsystem controller 120 may be implemented by various computing devices (e.g., one or more processors, controllers, and / or memory devices having instructions for configuring the processors or controllers) that meet the requirements of various functions of the transport device and are further described elsewhere herein. As previously described, the system processor 110 may communicate with various subsystem controllers 120 depending on the particular implementation. An example of hardware utilized for subsystem controller duties may be a microprocessor or microcontroller with a reduced instruction set computer (RISC) architecture. Depending on the requirements, the computer may be of various processing power and commonly available data bus configurations such as 8-bit to 64-bit architectures.

[0086] 3A illustrates one possible example where control distribution system 100 includes seven subsystem controllers 120 that interface with system processor 110 and one or more operational subsystems of the transport device and control the one or more operational subsystems of the transport device. While this example illustrates seven specific subsystem controllers 120, it should be understood that an implementation of control distribution system 100 may have less than seven or more than seven subsystem controllers 120. Additionally, an implementation may include some, all, or none of the specific examples shown in FIG. 3A.

[0087] In some implementations, one of the subsystem controllers 120 is a transport controller 321. In various cases, the transport controller 321 is responsible for controlling all of the subsystems 340 that directly perform the transport of the object or patient. For example, the transport controller 321 may control the movement of the transport platform and any conveyor belt via external sensors and motors. In various cases, user input is received by the HMI 320 and transmitted to the system processor 110. The system processor 110 (e.g., a manager system) then communicates the user commands to the transport controller 321. In some implementations, the system processor 110 determines optimal parameters of the transport function without requiring specific user input and communicates specific movements and state changes of the transport platform and transport belt to the transport controller 321. The transport controller 321 then controls one or more transport subsystems 340 to effect the movements and state changes.

[0088] As discussed above, in various cases, user input is received by the HMI 320. As will be discussed in more detail, in various implementations, the HMI 320 may also display information to a user or operator using one or more displays or other output devices. In some implementations, the transport device 200 may have one, two, or more separate HMI devices. As an example, FIG. 3A illustrates a control system 100 that includes both a front HMI 320a and a rear HMI 320b, which refer to the physical locations of the HMI devices 320a, 320b at the front and rear of the transport device 200, respectively. As another example, FIG. 3B illustrates a control system 100 that also includes both a front and a rear HMI 320a, 320b, and another HMI 320 integrated within a computing device 300 having a system processor 110. For convenience, references herein to HMI 320 are also applicable to front HMI 320a and rear HMI 320b unless otherwise stated or understood.

[0089] Although not required, in various cases, one or more HMIs 320 may operate as subsystems and / or subsystem controllers. By way of example, in FIG. 3A, each HMI 320a, 320b is illustrated as including a subsystem controller 120. The example in FIG. 3B shows that in some cases, each HMI 320, 320a, and 320b operates as a separate subsystem controller 120. In some cases, a single subsystem controller may control two or more HMIs (e.g., HMIs 320a, 320b). As another example, in some cases, the system processor 110 or another subsystem controller may control one or more of the HMIs 320. Other configurations are also possible depending on the particular implementation.

[0090] 3A , in some implementations, one of the subsystem controllers 120 is a lift and tilt controller 322 that interfaces with and controls one or more lift / tilt subsystems 341. In various implementations, the lift and tilt controller 322 allows a user to adjust the height and angle of the transfer platform. In various cases, user input is received by the HMI 320 and communicated to the lift and tilt controller 322. In some implementations, the system processor 110 determines the optimal height and angle of the transfer platform independent of the user input and communicates the height and angle to the lift and tilt controller 322. The lift and tilt controller 322 then controls various actuators and sensors in the one or more subsystems 341 to make the desired height and angle adjustments.

[0091] In some implementations, one of the subsystem controllers 120 is a transport controller 323. In various implementations, the transport controller 323 allows a user to drive the transport device 200 from one location or room to another location or room using one or more transport subsystems 342, including a drive wheel or multiple drive wheels, that receive inputs for acceleration, steering, and braking. In various cases, user inputs are received by the HMI 320 and communicated to the transport controller 323 by a manager system (e.g., the system processor 110). In some implementations, the system processor 110, via direct communication to the transport controller 323, determines the best route for transporting the transport device or intervenes on behalf of the user to maintain safety or automate the transport of the transport device.

[0092] 3A , in some implementations, one of the subsystem controllers 120 is a peripheral controller 324. According to some implementations, the peripheral controller 324 interfaces with and controls one or more peripheral subsystems 343 that include various sensors and / or actuators for controlling peripheral devices not involved in the actual movement of the transport device for patient transport.

[0093] In some implementations, one of the subsystem controllers 120 is a power system controller 325, which in some cases controls the power supply to all electronic components of the distributed control system 100 and the actuators of the transport device 200. In addition, in various cases, the power system controller 325 communicates with and provides power to the other subsystem controllers 120 and the system processor 110, and in some cases communicates with and provides power to the imaging subsystem 333. In some implementations, it may also provide power to an Internet of Things (IOT) gateway 331. Although examples refer to the IOT gateway 331, it should be understood that the external connection of the distributed control system 100 may also be another form of networking device, such as, for example, an intranet, a wireless access point, or a cellular modem.

[0094] In some implementations, the distributed control system 100 implements a Controller Area Network bus (CAN bus) network to allow one or more of the subsystem controllers 120 in the distributed control system 100 to communicate with each other without a host computer or complex dedicated wiring. This can allow the subsystem controllers 120 to communicate directly with each other without involvement by the system processor 110. Although, in various implementations, the system processor 110 can act as a nexus or intermediary between the subsystem controllers 120. Although a CAN bus network is illustrated in this example, it should be understood that any communication network viable for distributed computing can be utilized. Examples of possible communication networks include, but are not limited to, Recommended Standard 232 (RS232), Serial Peripheral Interface (SPI), and Transmission Control Protocol (TCP). It should also be understood that multiple parallel or sequential communication networks can be implemented by the subsystem controller 120. The subsystem controllers can also have communication networks implemented internally that do not communicate with the system processor 110.

[0095] According to various implementations, the system processor 110, the transfer controller 322, the transport controller 323, the peripheral controller 324, and the power system controller 325 collectively operate to enable basic operations and additional functionality for the transport device 200. In some cases, the basic operations can include, for example, height adjustment (e.g., up / down), angle adjustment (e.g., tilt left up / down, tilt right up / down, tilt forward up / down), pick up from left, pick up from right, drop off to left, and drop off to right. In some cases, the additional functionality can include various features beyond the basic operations. Further details of the system processor 110, the lift and tilt controller 322, the transport controller 323, the peripheral controller 324, and the power system controller 325 are provided below.

[0096] As discussed above, in some implementations, the HMI 320 includes an output device that provides feedback to the user. Such feedback can include the status of the transport device, thus allowing the user to monitor the operation of the transport device. It should be noted that the output device typically includes a display screen, but can additionally or alternatively include other types of output devices. Examples include, but are not limited to, an audio speaker device for communicating status by voice. Further details regarding user interface controls for the HMI 320, according to various implementations, are provided below with reference to FIGS. 4A-4I.

[0097] In some implementations, user input is received by the HMI 320 and communicated from the system processor 110 to the transport controller 321 to determine the orientation of the transport platform and how the conveyor belt extends for pick-up and drop-off. The relationship between the transport platform and the conveyor belt determines how the patient moves. In some transport operations, this relationship can be configured so that the patient has zero velocity relative to the speed of the conveyor belt during pick-up and drop-off. Ensuring this kinematic relationship between the conveyor belt and the patient minimizes the risk of shear motion of the conveyor belt against the patient's clothing or skin. Specifically, when the transport platform is extended to get under the patient and when it is retracted for drop-off, this configuration can improve the patient's comfort and overall experience. In some implementations, the transport device is bidirectional, meaning that the transport controller 321 can command the transport platform to perform transfer operations onto or off the transport device on both the left and right sides of the transport device.

[0098] As described above, in some implementations, the transport controller 321 controls the movement of the transport platform and any conveyor belt via sensors and motors. In some implementations, this includes encoders to sense the speed of the motors, linear displacement sensors to measure tension in the conveyor belt, and positioning sensors to determine the position of the transport platform. In some implementations, the transport controller 321 is preprogrammed with pre-determined limits or safety thresholds for the transport parameters being monitored. For example, on a transport device 200 with an open-ended conveyor belt, the transport controller 321 may know the length of belt required to perform a single transfer and can automatically reset the transport platform and conveyor belt to a default position in preparation for a subsequent or successive transfer. In some implementations, the transport controller 321 receives readings from device positioning sensors to determine if the transport platform is in position, extended, or out of position.

[0099] In some implementations, the transport controller 321 is configured to include some automated features that can improve the overall performance of the transport device. For example, the transport controller 321 can be configured to automatically make requests directly to other subsystem controllers, such as the lift and tilt controller 322 and the transport controller 323, to directly request adjustments to the global positioning of the transport device (e.g., vertical height, tilt angle, and position within the room) based on the patient's support surface (e.g., bed, stretcher) and the patient's location to ensure correct positioning before initiating a transfer sequence. In some cases, measurements from load sensors acquired by the other subsystem controllers 120 can be used by the transport controller 321 to sense the appropriate force / interaction between the support surface and the transport platform, thereby enabling the transport controller 321 to determine the global positioning. In some implementations, these automated features are included in the system processor 110 instead of the transport controller 321.

[0100] In some implementations, the transport controller 321 can automatically adjust device parameters and / or limits (e.g., platform speed, conveyor belt speed) based on the size of the patient (e.g., height and weight). Performing sensor fusion to combine all relevant data (patient size, patient position) can allow parameters and / or limits to be suitably determined for each patient. This allows the transport device to transport any person regardless of the person's size and weight. Further details of how the transport controller 321 can autonomously adjust and configure device parameters and / or limits are provided below with reference to FIGS. 5A and 5B.

[0101] In some implementations, to ensure patient safety during the transfer process, the transport controller 321 implements an error handling system that can automatically abort and stop any unsafe actions. In some implementations, the transport controller 321 also facilitates device-assisted servicing, whereby the transport controller 321 automatically repositions the transport device or a subsystem of the transport device to allow a technician or other person to have easy access to the transport device or a subsystem of the transport device.

[0102] As described above, the lift and tilt controller 322 allows the user to adjust the height and angle of the transfer platform. In some implementations, the angles that can be adjusted include a tilt angle that allows the transfer platform to be tilted laterally, so that the left and right sides can be tilted up or down, for example, + / - 5 degrees, and a Trendelenburg angle that allows the transfer platform to be tilted longitudinally, so that the head and foot ends can be tilted up or down, for example, + / - 10 degrees. In various implementations, the height, tilt angle, and Trendelenburg angle can be changed at any point during transfer. These changes can be automatically initiated by the lift and tilt controller 322, another subsystem controller 120, or requested by the system processor 110.

[0103] In some implementations, the lift and tilt controller 322 drives four linear actuators with feedback from limit switches and Hall effect sensors. In the event that the limits of the current sensing software are exceeded, the lift and tilt controller may make the decision to deactivate the linear actuators and stop the transfer operation. In some implementations, maximum tilt angle and maximum Trendelenburg angle thresholds are also defined within the lift and tilt controller 322 to prevent excessive tilting of the transfer platform, which may be unsafe for the patient.

[0104] In some implementations, the transport controller 323 controls the transport of the transport device, as described above. In some implementations, the transport controller 323 implements a propulsion system that controls motors that move the transport device, enabling assisted transport of the transport device according to gestures or input commands from a user via the HMI 320. In some implementations, the transport controller 323 may include additional sensors and data inputs to enable automated transport of the transport device 200. It should be understood by those familiar with automated vehicle navigation that in such implementations, additional controllers may be integrated to enable, for example, simultaneous localization and map building, or technologies such as GPS (Global Positioning System).

[0105] As described above, the peripheral controller 324 interfaces with one or more peripheral subsystems, including a variety of different sensors for detecting and controlling those not involved in the actual movement of the transport device for patient transport. In some implementations, the peripheral controller 324 communicates with sensors to detect the size and position of the patient. In some implementations, sensors in the lift / tilt subsystem(s) 341 in the transport device can measure the patient's weight, and distance sensors in the peripheral subsystem(s) 343, such as time-of-flight, infrared, or ultrasonic sensors, are attached to the transport device to monitor the positioning of the patient during transport by measuring the distance between the sensor and the patient. In some implementations, the peripheral controller 324 can provide acquired data directly to the transport controller 321, so that the transport controller 321 can customize and determine device parameters and / or limitations for each patient. This is one example of such an implementation, but it should be understood that the configuration of the subsystem controller 120 and the system processor 110 is intended to be optimized to be adaptable such that individual sensory inputs can be positioned throughout the transport device in a manner that allows for the most advantageous overall configuration. Further details of how the transport controller 321 may automatically adjust device parameters and / or limits are provided with reference to Figures 5A and 5B.

[0106] In some implementations, the peripheral controller 324 provides safety features for the distributed control system 100 (e.g., alone or in combination with the peripheral subsystems 343) to ensure patient and user safety. These safety features can include one or more of guardrail sensing, support surface proximity sensing, wheel lock sensing, patient position sensing on the platform, and service shroud intrusion detection. According to various implementations, the guardrail sensing system detects the position of the guardrail. If the rail is up, the sensor is on and if the rail is down, the sensor is off. In various cases, the state of the sensor is communicated to the rest of the distributed control system 100. In various implementations, if the sensor is off, transfer is not allowed because this means the patient side guardrail is down.

[0107] According to various implementations, the sensor for support surface proximity sensing detects the presence of a patient support surface, such as a bed, and measures the distance between the device and the support surface to ensure that the device is close enough to the support surface. If the support surface is not detected or if the device is too far from the support surface, for the safety of the patient, the peripheral controller 324 does not allow the transport device 200 to perform the patient transport motion.

[0108] In some implementations, the peripheral controller 324 implements a wheel lock system to detect whether the wheels of the transport device are locked or unlocked, and if the wheels are not locked, transport is not allowed to occur.

[0109] In some implementations, the peripheral controller 324 is connected to sensors in one or more peripheral subsystems 343 to detect the position and orientation of the patient when positioned over the body of the transport device. The sensors can detect if the patient is occluding the side guards and if the patient is fully supported by the body of the device. The peripheral controller 324 communicates this sensor information to the system processor 110, which can notify the user via the HMI 320 to take corrective action or communicate to the transport controller 321 to automatically adjust the position of the patient within the body of the device.

[0110] In some implementations, the peripheral controller 324 is connected to sensors in one or more peripheral subsystems 343 to detect a service shroud intrusion, such as someone opening a panel or cover on the transport device. This detection can, in various cases, be communicated to the power system controller 325 so that the power system controller 325 can shut off high power for the actuators of the transport device. In such a case, normal applications can be disabled and the transport device can be serviced.

[0111] As described above, the power system controller 325 controls the power supply to the electronic components of the distributed control system 100 and to the actuators of the transport device. In some implementations, the power system controller 325 controls the power supply to the actuators of the transport device through contactor switches configured to power the motor drivers on and off. In some implementations, the power system controller 325 operatively controls electronic circuit boards having individually selectable and switchable power outputs to deliver energy (e.g., 12V) to one or more subsystem controllers 120. In some implementations, the power system controller 325 has enough power connections to monitor all voltages and currents on the power rails in the transport device, although in some cases it may monitor less than all power levels. In some cases, sensors may additionally monitor the total current in the transport device.

[0112] In some implementations, the power system controller 325 is coupled to one or more power subsystems 325a, including, in some cases, a battery management system (BMS), which monitors and interacts with the battery to gain insight into the state and health of the battery, such as the charge level and any errors or problems. In some cases, the power system controller 325 can determine from the BMS when the battery needs to be charged and then power down the transport device 200 so that the battery can be charged.

[0113] In some implementations, there is a fan located within the transport device 200 for cooling purposes, and the power system controller 325 controls the operation of the fan. If the temperature within the transport device 200 becomes too high, the power system controller 325 turns on the fan to prevent overheating.

[0114] In some implementations, transport device 200 has two emergency stop (E-Stop) buttons, one on each end of transport device 200. In various cases, the E-Stop buttons can be pressed to immediately stop all actions. In some implementations, power system controller 325 has an energy dump system that monitors E-Stop conditions and ensures that the transport device stops immediately when either E-Stop button is pressed.

[0115] In some implementations, the transfer device 200 additionally has a wired or wireless remote control. The remote control (sometimes referred to as a control pendant) allows the user to leave the device body and approach the object (e.g., the patient) during the transfer process for monitoring and observation purposes. In such implementations, the remote control can also have an E-Stop button.

[0116] In some implementations, the power system controller 325 ensures that the transport device 200 immediately stops upon various other triggers. For example, upon a service shroud intrusion, the power system controller 325 can stop the transport device. The service shroud intrusion can be detected by sensors in one or more peripheral subsystems 343, and the peripheral controller 324 can signal an indication of the service shroud intrusion to the power system controller 325.

[0117] In some implementations, the power system controller 325 has a notification or warning system for communicating messages and status reports to an operator. An example of such a system is an audio warning system, such as a buzzer, that provides an audio output to alert a user of an error or possible safety hazard. It is readily understood that a variety of warning systems can be utilized, such as tactile warnings through the handlebars of the transport device 200, indicator lights or LED strips, or audible voice warnings generated by the subsystem controller.

[0118] In some implementations, the HMI 320 may include a display screen and / or other output devices for communicating information, as well as buttons and / or other input devices for receiving user input that can be transmitted to and forwarded by the system processor 110.

[0119] 3A , in some implementations, the control system 100 of the transport device 200 is connected to a communication network (e.g., internal, local, external, etc.) to provide access to various types of data. By way of example, in some cases, the distributed control system 100 is connected to a cloud network 332 through an IoT gateway 331. In such cases, developers can receive diagnostics regarding the performance of the transport device, the real-time status of the transport device, and can upload firmware changes to the transport device. In some cases, users can receive data about the status of transports, the number of transports completed, patient information such as weight and location, and various other types of data.

[0120] As shown in FIG. 3A, in some implementations, the distributed control system 100 interfaces with at least one imaging device or system 333. According to various implementations, the imaging device or system 333 may be considered a device subsystem of the transport device 100 without its own imaging subsystem controller. In such cases, the system processor 110 and / or one or more other subsystem controllers may communicate with the imaging device 333. In some cases, the imaging device or system 333 is considered an operating device subsystem that includes an imaging subsystem controller. In such cases, the imaging subsystem controller may communicate with the imaging subsystem, and the system processor 110 may communicate with the imaging subsystem controller and / or the imaging subsystem itself. By incorporating imaging into the transport device, it can enable more precise and accurate patient positioning and further patient monitoring. In some cases, the imaging device 333 can improve the patient support surface proximity sensing capabilities of the transport device and prevent or reduce gaps between the support surface of the transport device and the transport platform during transport operations. According to various implementations, the imaging device 333 can include a radar device, a sonar or ultrasound device, and / or a camera (standard / stereo / depth) device. A combination of imaging devices is also possible, including different types of imaging devices. For example, the distributed control system 100 can interface with both a radar device and a camera. In some implementations, the system processor 110 learns how to estimate the patient's mass and / or volume using image processing, as described below with reference to FIG. 5D.

[0121] FIG. 3B is a block diagram of a distributed control system 100 similar in many respects to the control system 100 of FIG. 3A and described above. Unless otherwise indicated, the description of various aspects of the control system 100 in FIG. 3A also applies to the control system 100 in FIG. 3B. As shown in FIG. 3B, in various implementations, the system processor 110 incorporates HMI 320 functionality that allows a user to interact with the transport device 200. In such implementations, the system processor 110 can be incorporated as part of the computer 300 to take on additional functionality. Although the HMI 320 functionality is depicted as being bundled with the system processor 110 in this implementation, it should be understood that other subsystem controllers 120 can also be incorporated into the system processor 110 in a similar manner.

[0122] 4A-4I, diagrams of example user interface controls for the HMI 320 of the transport device 200 are illustrated according to various implementations. FIG. 4A shows an example location 402 of the user interface controls on an end of the transport device 200. Note that in some implementations, the other end of the transport device 200 may have the same user interface controls. FIG. 4B shows a close-up view of the example location 402, including example components of the user interface controls. As shown in FIG. 4B, in various implementations, the user interface controls include a control pendant 410 having a cable 420, a first keypad 430, a second keypad 440, and a display screen 450. The control pendant 410 is wired using the cable 420, but in other implementations, the control pendant 410 is wireless, in which case the cable 420 can be omitted. Note that the depicted components and their locations on the transport device 200 are for illustration only and are provided for exemplary purposes only. Other implementations are possible.

[0123] 4C-4E show details of the control pendant 410 according to various implementations. The control pendant 410 has a membrane pad 411 for receiving user input, an E-Stop button 412 for immediately stopping all actions, an indicator light 413 for providing user feedback, and a cable gland 414 for wired implementation. FIG. 4F shows details of a first keypad 430 including an up button 431 for raising the transport device 200, a down button 432 for lowering the transport device 200, a left tilt button 433 for tilting the transport device 200 to the left, and a right tilt button 434 for tilting the transport device 200 to the right. FIG. 4G shows details of a second keypad 440 including four buttons 441-444 for selecting a patient transfer as depicted, a play button 445 for progressing the selected transfer, and a pause button 446 for pausing the transfer. Other user interface controls are possible in addition to or instead of those shown in the drawings.

[0124] 4H and 4I show details of an HMI tablet 460 for use with a transport device 200, according to various implementations. FIG. 4H illustrates one possible implementation of an HMI tablet 460 removably mounted between a first keypad 430 and a second keypad 440 of a transport device 200, in place of the display screen 450 illustrated in the example shown in FIGS. 4A and 4B. FIG. 4I illustrates mounting of the HMI tablet 460 near a corner of the transport device 200, according to various implementations. Of course, other locations and manners of mounting the HMI tablet 460 are possible in various implementations.

[0125] In some cases, incorporating some or all of the functionality of the HMI 320 into the HMI tablet 460 gives the operator increased mobility when operating the transport device 200 without compromising the functionality of the HMI 320, for example, by improving ease of use compared to a conventional pendant design. In some cases, the touch screen component of the HMI tablet 460 can be used when attached to the transport device 200 as well as when removed from the transport device 200, at which point it can be used like a tablet. When attached to the device, the HMI tablet 460 can also be plugged into its communication and power ports. In some cases, the HMI tablet can automatically charge a battery when attached and communicate with the device using a physical wire. When the HMI tablet 460 is not plugged or attached to the device, the HMI tablet 460 relies on battery power and communicates with the transport device 200 via a wireless communication connection (e.g., a Bluetooth connection).

[0126] According to various implementations, the operator can change the orientation of the HMI screen for ease of use when the HMI is removed from the transport device 200 and in “tablet mode”. In some cases, a hand strap can be attached to the back of the HMI for safety and to allow a more secure grip. In some cases, the HMI tablet 460 can be used with an extension cord if it is not fully charged but the operator still wants to utilize the tablet mode option. In such cases, the power and communication modes can be approximately the same as when the HMI tablet 460 is attached and plugged into the transport device 200. In some cases, the accessibility and location of the HMI 320 on one or more (e.g., front and rear) sides of the transport device 200 still apply to the implementation of the HMI tablet 460.

[0127] According to various implementations, the HMI tablet 460 may also implement "find my tablet" functionality. For example, in some cases, the transport device 200 includes a button located in the missing HMI mounting area that can be pressed if the HMI tablet 460 is not located, and pressing the button can send a command to the HMI tablet 460 to, for example, beep and flash a light to aid in locating the HMI tablet 460.

[0128] 5A-5F are flow diagrams illustrating various transport device 200 routines, according to various implementations. In various cases, a manager system (e.g., a system processor 110 configured with appropriate instructions) and / or one or more subsystem controllers 120 execute the routines or methods in conjunction with various user inputs and / or other conditions. According to various implementations, the transport routines may be enhanced for functionality, safety, or ease of use by adding additional subroutines that may be executed serially or in parallel to the transport operations. FIGS. 5A-5F also include examples of how these transport routines may be improved and expanded with the addition of electronic imaging to the distributed control system.

[0129] 5A is a flow diagram of a method 500A for coordinating the transport of an object (e.g., a patient) according to various implementations. In step 501, the manager system receives and processes information about a user's input regarding transport parameters from the HMI 320 and initiates the transport process accordingly. In step 502, the manager system signals the transport controller 321 to extend the device platform towards the object.

[0130] As the device platform extends towards the object, parallel transfer execution activities (503) may be completed. For example, in some cases, the manager system may coordinate the multiple subsystem controllers 120 to detect a support surface under the object to efficiently complete the transfer. An example of such a surface detection method is further described in FIG. 8B. Another possible parallel activity involves the transfer controller 321 executing a method for detecting material obstacles when extending the device platform. An example of such a material obstacle detection method is further described in FIG. 8D. Another possible parallel transfer execution activity (503) is the coordination (5031) of the multiple subsystem controllers 120 to optimize transfer efficiency, such as coordinating the transfer controller 321, lift and tilt controller 322, and peripheral controller 324 to optimize the speed and path of the platform under the object. In various implementations, the manager system monitors the parallel transfer execution activities (503) and modifies the transfer behavior accordingly.

[0131] After extending the device platform under the object (504), the manager system coordinates with the HMI 320 to request confirmation from the user to continue with the next step of the transfer, described as transfer on in step 505. If confirmation is received in step 505, the manager system signals the transfer controller 321 to move the object towards the device (506). Parallel activity step 503 is again initiated in parallel with step 506. According to various implementations, the manager system coordinates multiple subsystem controllers 120 to execute a method for centering the object over the device base (506) to prevent unsafe and uncomfortable conditions. An example of such a method is further described in FIG. 8E.

[0132] In step 507, the manager system waits for the HMI 320 to communicate the user's intent to transfer the object (e.g., a patient) from the device. Upon receiving the user's input regarding the transfer parameters, the manager system sends a signal to the transfer controller 321 to move the object towards a subsequent support surface, which can be different or the same as the support surface to which the object was originally moved. Step 503 is executed again once the transfer controller 321 has moved the object onto the support surface.

[0133] When the transport controller 321 completes the movement of the object onto the support surface, the manager system waits for the HMI 320 to communicate a user confirmation to complete the final step of the transport process, described as retraction in step 509. When confirmation is received, the manager system signals the transport controller 321 to retract the device platform from under the object and move the platform back towards the center of the device (510). While the transport controller 321 moves the platform towards the device, the parallel transport activity (503) is again performed. During this process, the manager system may initiate methods such as obstacle detection 800D to monitor for any displacement or position issues due to obstacles occurring between the support surface and the device. When the platform returns to the center of the device, the transport is complete in step 511.

[0134] FIG. 5B is a flow diagram of a method 500B for coordinating the transfer of an object (e.g., a patient) using image processing, according to various implementations. The transfer method 500B includes several steps similar to the transfer method 500A illustrated in FIG. 5A, and the relevant description of FIG. 5A also applies to the various steps of the transfer method 500B. Similar to the transfer method 500A, the transfer method 500B begins with a user initiating a request for a transfer-on operation (501). The manager system can also initiate concurrently executing activities (503), as described above.

[0135] Concurrently, system processor 100 and / or subsystem controller 120 are configured to initiate (512) capture of images of the object transfer. The term "image" is used herein to refer to a representation of an object, support surface, and / or other environment outside of transfer device 200 that is sensed or otherwise acquired by transfer device 200. Additionally, unless otherwise indicated, the terms "image," "image capture," "image data," and "imaging" are used herein to refer to both a still image and a series of sequential images forming a video.

[0136] It should be understood that image capture may include collecting many forms of electromagnetic radiation, such as, but not limited to, the visual spectrum, infrared, and x-rays. In some cases, image capture may involve detection of sound waves, such as sonar or ultrasound. The transport device 200 may be configured with one or more technologies for capturing images. As described with respect to FIGS. 3A and 3B, in various cases, the transport device may include an imaging device 333, such as, for example, a radar device, a sonar or ultrasound device, and / or a camera (standard / stereo / depth) device. Combinations of two or more imaging devices, including various types of imaging devices, are also possible. Examples of locations for image capture may include the device platform, a support surface, the surroundings of the device (i.e., a room), and an object (e.g., a patient).

[0137] Following the initiation of image capture (512), multiple parallel processes (513) can be performed based on the acquired images. In various implementations, the addition of image-based analysis can improve the safety and effectiveness of the transfer process. Some examples of possible parallel processes 500C, 500D, 500E, and 500F are described with respect to FIGS. 5C-5F. For example, FIGS. 5D and 5E present a method of analyzing the captured images to generate additional information to aid other routines. As an example, image analysis can be used to improve the accuracy of extending the device platform (502), such as in routine 800A for aligning the transfer device, as shown in FIG. 8A. Image capture (512) can be initiated in parallel during all other transfer steps, according to various implementations. As another example, in some cases, analyzing the captured images (e.g., according to the method presented in Figures 5C-5F) can provide additional data for centering the object (506), as well as monitoring new transfer areas, detecting obstacles, and preventing unsafe conditions during the transfer operation.

[0138] 5C is a flow diagram of a method 500C of performing image processing to determine at least one variable associated with the transport of an object, according to various implementations. The image processing method 500C can be performed by a manager system implemented by the system processor 110 of the distributed control system 100 shown in FIG. 3. In various implementations, the manager system includes a machine learning algorithm for determining the at least one variable. According to various implementations, the method 500C of FIG. 5C can be performed by any processor of the transport device 200, including a processor that may not be part of the distributed control system 100.

[0139] As shown in FIG. 5B, the method 500C begins following image capture (512). A processor executing the method receives one or more captured images from at least one imaging device. By way of example, the processor may receive a sequence of images forming a video feed. Turning to FIG. 5C, at step 532, the processor determines at least one variable using image processing of the captured images, such that the at least one variable is related to the transport of the object by the transport device.

[0140] There are many possibilities for the at least one variable. In some implementations, the at least one variable includes a mass and / or volume of the object. In some implementations, the at least one variable includes a position and / or orientation of the object. In some implementations, the at least one variable includes a topography of the support surface, such as dimensions of the support surface, smoothness of the support surface, or orientation and tilt of the support surface.

[0141] In some implementations, the processor evaluates the risk of damage to the object based on at least one variable that has been determined. For example, the processor may determine that there is a risk of injuring the patient due to the patient's position or orientation (e.g., the patient is facing down), and therefore the patent transfer can be postponed or stopped. In other control algorithm implementations, the risk of damage to the object can be based on the probability of an unintended impact or excessive force of the transfer device while the object is being transferred. For example, through the use of a depth camera, the imaging system can predict the platform extension distance before it is likely to interact with the patient, thereby adjusting its extension path accordingly in terms of stroke versus height. An example of such a process is described in more detail below with reference to FIG. 5E.

[0142] In some implementations, the captured image (e.g., a video feed) may be overlaid with desired assistance for the operator. Such assistance may include alignment assistance when driving the transport device 200 during its transport, alignment of the transport device to a support surface, or alignment to the object being transported. An example of such overlay is depicted in FIG.

[0143] In some implementations, a processor (e.g., a manager system, a subsystem controller, or another processor) records the captured images (e.g., a video feed) for future playback. In some implementations, the processor establishes an external data connection and transmits the images via the external data connection to an external receiving unit for monitoring and viewing (e.g., by a remote operator or user, or for analysis by a remote computer system).

[0144] According to various implementations, an imaging device 333, which may be a digital camera-based approach (e.g., CMOS, CCD, infrared, depth camera), or a combination of digital cameras, may be used to perform monitoring and / or surveillance of the transfer of a patient (or other object). For safety purposes, the camera 333 may determine if the patient is in an unsafe position (e.g., prone) and should not be transferred by the transfer device 200. During the process of transfer, the camera 333 may monitor if the patient is agitated or if the patient begins to move or roll into an unsafe position. In such cases, the manager system may intervene to take appropriate measures, such as stopping the transfer. This approach may also be used to serve as a data record for employee monitoring or insurance audit purposes if the captured images (e.g., video stream) are recorded during the transfer process. For example, if an accident occurs (e.g., if the patient falls or is injured), the camera footage may be played back as evidence of what occurred during the event.

[0145] In some implementations, the processor determines parameters and / or limitations for the transfer device 200 to transfer the object based on at least one variable that has been determined. For example, the processor may determine the parameters and / or limitations based on the mass and / or volume of the object. In some implementations, the processor receives feedback regarding forces measured during transfer of the object and adjusts the parameters and / or limitations according to the feedback. Examples of such methods are described in further detail below with reference to FIG. 5D.

[0146] 5D is a flow diagram of a method 500D of estimating mass and / or volume using image processing. The method may be performed by a processor, such as the system processor 110 of the distributed control system 100 shown in FIGS. 3A and 3B. In certain implementations, the manager system performed by the system processor 110 includes a machine learning algorithm that predicts the mass and / or volume. More generally, the method of FIG. 5D may be performed by any processor of the transport device, including a processor that may not be part of the distributed control system.

[0147] In various implementations, prior to the start of a transfer sequence, the processor incorporates data acquired from sensors and cameras in various subsystems of the transfer device 200 to perform an estimate of the patient's mass and / or volume. After a user initiates a transfer request (501), image capture begins (512) and the processor performs a pre-assessment of the cameras and distance sensors. Such pre-assessment may include, for example, measuring the distance to the edge of the support surface or initial interaction with the patient. In step 513-10, the processor performs an image-based estimation of the patient's volume and mass according to the algorithm configuration. For example, in various cases, the processor estimates the weight of the object based on a count of the object's pixels and the object's density.

[0148] In the example of transferring a patient, the density of a human is well defined. Thus, in various cases, the processor counts the number of pixels that make up the patient in the image and then determines the size of the patient in pixels. The processor is configured to estimate the volume of the patient based on the number of pixels and calculate an estimated mass of the patient based on the estimated volume and density of the patient. In some cases, the processor is configured to first convert the size of the patient in pixels to real world dimensions (e.g., pixels per mm) before estimating the volume and / or subsequently calculating the mass. Thus, the processor (e.g., the manager system) can estimate the total mass and weight distribution of the patient and, as a result of this prediction, can also predict the expected forces on the platform and where these forces will be experienced during the platform extension process. The mass and weight distribution of the patient combined with the support surface properties can also be used by the manager system to predict the upward forces on the platform. Such an estimate is used to determine the limits of the transfer parameters and / or transfer sequence.

[0149] During the transfer sequence, in step 513-11, the processor acquires data from a data acquisition (DAQ) system corresponding to forces acting downward (e.g., from the patient), upward (e.g., from the support surface), or in another direction on the device platform and / or device body, as well as device platform extension distances corresponding to the volume and / or mass of the patient exerting forces on the platform during various stages of the transfer process. Data from the DAQ system may include, for example, sensor data measured by the peripheral controller 324 and / or the lift and tilt controller 322. In step 513-12, the processor analyzes the measured force data (e.g., from force sensors attached to the platform structure or load cells at the base of the device) to determine the force and extension used to extend the platform under the patient based on the data from step 513-11. In step 513-13, the processor compares the force and extension distance from step 513-12 to the expected force and extension based on the image-based estimation from step 513-10.

[0150] If the processor determines that the force and extension distance from step 513-12 match what is expected within a defined tolerance (e.g., within + / - 5%), no changes are made to the algorithm configuration and the transfer sequence proceeds until it is completed. However, if the processor determines that the force and extension from step 513-12 do not match what is expected within a defined tolerance, then in step 513-14 the processor adjusts the algorithm configuration and provides training data to the image weight estimation routine. This can allow the transfer parameters and / or limits for the transfer sequence to be adjusted in real time for the current transfer sequence. Additionally or alternatively, adjustments to the algorithm configuration can allow for improvements to subsequent transfer sequences. Adjustments to the algorithm configuration can include modifying the expected platform extension force, belt tension, preset platform transfer height (e.g., for required compression into the support surface) or angle, to name a few examples.

[0151] By improving the configuration of the algorithm over time, the actuators of the transport device 200 may utilize as much force as may be appropriate given the size (e.g., volume and / or weight) of the object (e.g., patient) being transported. This may avoid situations where too much force is used, resulting in a too rough or even dangerous transport, as well as situations where too little force is used, resulting in a transport not being performed successfully. Thus, the predictive algorithm may help improve patient comfort and satisfaction, for example, as it adjusts the transport parameters and / or limits for each patient. Additionally, it is a safety feature, as the algorithm may prevent high forces from being applied to small patients.

[0152] FIG 5E is a flow diagram of a method 500E of assessing transfer risk using image processing, according to various implementations. The method can be performed by a processor, such as the system processor 110 of the distributed control system 100 shown in FIG 3A and FIG 3B. In certain implementations, the manager system performed by the system processor 110 includes a machine learning algorithm for determining transfer risk. More generally, the method of FIG 5E can be performed by any processor of the transfer device, including a processor that may not be part of the distributed control system.

[0153] As shown in FIG. 5E, the method 500E begins following image capture (512). In various cases, a pre-staging step 513-20 involves image-based analysis of the patient's position, face and limb detection, distance to extend the platform for the first interaction, angle of approach, and possible obstacles on the support surface. Facial recognition, edge and object detection, and geometric transposition are examples of some methodologies that can be used to perform the analysis described in step 513-20. Following this analysis, a patient orientation analysis occurs (513-21), which can include analyzing the patient's body rotation and the direction of the patient's face. To accomplish this, those skilled in the art will recognize that there are multiple image analysis algorithms that can identify key body structures (e.g., arms, elbows, head, etc.) to identify the orientation of the transferred patient (commonly referred to as the "pose" of the person in the image). If the patient orientation analysis detects a problem (e.g., the transfer process begins with the patient prone), the transfer is stopped (514).

[0154] If no problem is detected in step 513-21, the processor executes a real-time risk determination algorithm (513-22). In some cases, the real-time risk determination involves comparing the patient's orientation, platform interactions, and detected forces to the same parameters expected from image analysis. An example may include comparing the patient's starting orientation to its orientation during transport and its changes using the image analysis methods outlined above. Other examples may include, but are not limited to, analysis of the rate of change of the patient's orientation, analysis of the patient's facial expressions in an effort to detect levels of pain or agitation, and analysis of potentially related behaviors such as improper body mechanics (e.g., joints being pushed improperly or bent improperly due to the transport process).

[0155] According to various implementations, combining these types of patient orientation analyses with the force and extension algorithms discussed above can generate more sophisticated and accurate risk analyses. For example, the forces experienced by the transport device DAQ system should be lower during the "limb" portion of the platform extension (e.g., arm exit) compared to the patient's mid-plane, where peak forces should be seen. Using these analyses, a real-time transport risk analysis (513-23) can then be generated based on a predefined risk profile determined as a reference for comparison. Upon detecting a problem (i.e., risk is outside of a predefined range), the transport is stopped (514). In other cases, the transport is allowed to proceed in a manner that includes continuing the real-time risk determination (513-22).

[0156] FIG 5F is a flow diagram of a method 500F of relaying identified risks and other information to a user or operator of the transport device 200. The method can be executed by various processors, including, for example, the system processor 110 of the distributed control system 100 shown in FIG 3, in coordination with the HMI 320. According to various implementations, the method begins with capturing one or more images (512) and then transmitting the image(s) to the HMI 320 display (513-30). The method 500F further includes overlaying the transport platform and displaying the identified risks on the HMI display (513-31).

[0157] FIG. 6 is a perspective view of a transport device 200 with an imaging system according to various implementations. The transport device 200 includes an imaging device 333 located at one end of the transport device 200. In some cases, the imaging device 333 can be a radar device, a sonar or ultrasonic device, and / or a camera (standard / stereo / depth) device. In the example shown in FIG. 6, the imaging device 333 captures an image of an area 600 adjacent to the transport device 200. In some implementations, the captured image is displayed on the HMI 320 display 450 and / or the HMI tablet 460 for viewing by the device operator. FIG. 6 shows an example where a captured image of an obstruction 602 is displayed on the display 450. In some cases, the image is overlaid on the display 450 with desired assistance for the operator. Such assistance may include alignment assistance when driving the transport device 200 during its transport, alignment to a support surface of the transport device, or alignment to an object being transported.

[0158] 7 is a block diagram of a distributed control system 100 for a transport device 200, according to various implementations. The distributed control system 100 can be implemented in any suitable transport device, such as any of the examples of transport device 200 discussed herein. It should be understood that the distributed control system 100 illustrates one particular implementation and is provided for exemplary purposes only. Other implementations of the distributed control system 100 are possible and are within the scope of the present disclosure.

[0159] 7, the distributed control system 100 includes a system processor 110 coupled to multiple subsystem controllers 120. As can be appreciated, each of the subsystem controllers 120 is configured to perform the functions of the transport device 200. Meanwhile, the system processor 110 is configured to monitor and communicate with the subsystem controllers 120. According to various implementations, the distributed control system 100 is configured to interact with, among other things, an environment 731, an object / patient 732, a user or operator 733, and a cloud network 332. In some cases, the distributed control system 100 also includes a redundant system processor 110a in case of failure of the system processor 110.

[0160] The functions performed by the system processor 110 and the subsystem controller 120 can vary among various implementations. In some cases, the distributed control system 100 can include multiple subsystem controllers with corresponding functionality, as shown in FIG. 7. Some of the various functions can be similar to those already described above with reference to FIG. 3. In various cases, one or more of the subsystem controllers control and / or are part of one or more corresponding operational subsystems of the transport device, as discussed above. With reference to FIG. 7, in the illustrated example, the system processor 110 communicates with and oversees multiple subsystem controllers, including, for example, device failsafe 721, device monitoring 722, imaging 333, object interaction 724, human machine interface 320, patient diagnostics 726, and connectivity suite 727. Additional and / or alternative operational subsystems and corresponding subsystem controllers 120 are also possible in various implementations.

[0161] 8A-8E illustrate some examples of possible routines and decisions that the manager system is configured to execute in various implementations. Unless otherwise specified, references to one or more subsystem controllers 120 refer to the use of one or more of the subsystem controllers 120 described herein, including the examples illustrated and discussed with reference to FIGS. 3A and 3B, as well as other possible subsystem controllers 120. As an example, in some cases, the manager system collects and / or receives information from various sensors via one or more subsystem controllers 120, including peripheral controller 324, transfer controller 321, lift and tilt controller 322, transport controller 323, and / or power system controller 325, as appropriate. As another example, in some cases, the manager system instructs and / or coordinates with the subsystem controllers to move or stop moving a portion of the transport device 200. Such subsystem controllers 120 may include, for example, peripheral subsystem controller 324, transfer controller 321, lift and tilt controller 322, transport controller 323, and / or power system controller 325, as appropriate.

[0162] 8A is a flow diagram of a method 800A for aligning the transport device 200 according to various implementations. The method 800A includes subroutines or autonomous operations that the manager system can execute to align the transport device 200 with respect to a support surface (e.g., support surface 20, support surface 30 in FIGS. 2A-2C) according to various implementations. In steps 801 and 802, respectively, the manager system collects information from the HMI 320 to receive a user request and from the subsystem controller 120 to perform an analysis, and determines the position and orientation of the support surface (804) to identify any obstacles or obstructions (803).

[0163] Based on its analysis in steps 803 and 804, the manager system can make a decision (805 and 806) to align the device or deny (807) the user's request to continue the alignment subroutine 800A. When the manager system decides to continue the alignment 800A, it instructs the subsystem controller to calculate a trajectory 808 across the floor to align the device and the support surface in the X-axis and Y-axis parallel to the floor, and propel the transport device 200 accordingly (809). The manager system collects further information (810, 811) to identify obstructions (812) and makes a decision (813) to continue or abandon the alignment subroutine 800A. When the manager system decides to continue the alignment 800A, it instructs the subsystem controller 120 to adjust (815) the height and angle of the transport platform 202 in the Z-axis perpendicular to the floor so that the transfer is possible. In some implementations, the manager system may further ask the user or operator to confirm the alignment (817).

[0164] 8B is a flow diagram of a method 800B for detecting contact between a device transport platform and a support surface, according to various implementations. The method 800B includes subroutines or autonomous operations that the manager system can execute to detect contact between the transport device 200 and a support surface (800B). The manager system coordinates the subsystem controller 120 to lower the transport platform (821) and read data from the multiple force sensors (822). The manager system then calculates (823) a reaction moment for the transport device 200. One possible way to calculate this reaction moment involves calculating the sign and magnitude of the acceleration of the force sensed at both lateral halves of the device when the reaction moment acts along the longitudinal centerline of the device.

[0165] In step 824, the manager system determines whether the reaction moment is greater than a predefined threshold adjusted for the mass, static load, and dynamic load of the transport device. One possible method of determining whether the reaction moment meets the threshold involves verifying that the sign of the acceleration of the force acting on the half of the device closest to the patient is opposite to the sign of the acceleration of the force acting on the opposite half of the device. In some implementations, the approximate threshold for the reaction moment of a transport device in contact with a surface is 150%-300% of the typical reaction moment of the same transport device rising or falling in open air. However, this value may vary depending on the mechanical configuration of the particular transport device. Thus, in various implementations, the method 800B may be used for different device mechanical architectures by determining a specific trigger threshold corresponding to a particular transport device.

[0166] According to various implementations, a determination that the threshold has not been met causes the manager system to return to reading data (822) and calculating the reaction moment (823) until the threshold is met or the method is otherwise aborted. When the manager system determines that the reaction moment is greater than the threshold, the manager system makes a further determination that a support surface has been detected (825). In such a case, the overall transfer process is then continued. In some cases, the transfer process continues at step 826 by then determining one or more characteristics of the support surface. In some cases, the manager system may search for multiple reaction moments that then change direction to detect multiple contact points where support is increasing.

[0167] FIG. 8C is a flow diagram of a method 800C for determining characteristics of a support surface (e.g., support surface 20, support surface 30 in FIGS. 2A-2C) according to various implementations. Method 800C includes subroutines or autonomous operations that the manager system may execute to determine 800C characteristics of the support surface. As an example, in some cases, the manager system may determine characteristics including width and type of mattress (e.g., air or foam mattress). Method 800C includes the manager system coordinating the various subsystem controllers 120 at step 832 to lower the device transport platform onto the support surface. The manager system also collects information from the various subsystem controllers 120, including collecting force sensor data (833) and vertical displacement (834). In some cases, the manager system calculates a spring constant from the collected data (835) to inform the force analysis to be applied during the transfer process, the displacement required to achieve the desired compression set point, and to determine the expected force vs. displacement profile as a function of the variation in the support surface, and then applies the spring constant to subsequent transfer calculations (836). This can be useful in situations where the support surface is changing dramatically between patient transfers (e.g., air mattress vs. foam). Overall, this process can provide the benefit of optimizing workflow by not requiring the user to input the support surface type in order to adjust the transfer algorithm and optimize transfer efficiency as well as patient comfort.

[0168] FIG. 8D is a flow diagram of a method 800D for detecting obstacles according to various implementations. The method 800D includes subroutines or autonomous operations that the manager system can execute to detect material obstacles of 800D during transfer. According to various implementations, the manager system coordinates with the transport subsystem controller 321 to match the displacement of the conveyor belt to the displacement of the transport platform according to the kinematic requirements of each stage of the transfer process. As an example, in some cases, the transport controller 321 is configured to displace the conveyor belt by the same amount as the displacement of the transport platform during a stage where an object (e.g., a patient) needs to be moved with the same displacement as the platform. Some examples include when an object is being moved onto the transport device 100 after the platform has been inserted below, and when a patient needs to be placed back onto the support surface. In another example, the transport controller 321 may be configured to displace the conveyor belt by twice the displacement of the transport platform, for example, during a transport phase involving the platform moving under the patient or removing itself from under the patient (i.e., picking the patient up from the support surface or returning the patient to the support surface).

[0169] After determining the actual belt displacement, the manager system determines whether there is a displacement error (842). In some cases, determining the presence of a displacement error includes determining the difference between the expected conveyor belt displacement and the actual conveyor belt displacement. In some cases, a threshold is applied to the displacement difference, and an error occurs when the difference exceeds the threshold. According to various implementations, the threshold is selected based on the sensitivity requirements of the current stage of the transfer. For example, when transferring the patient to the device, the patient should not move so significantly that there is a risk of falling off the transfer device. In some cases, based on the limits of control, and as a general guidance, the positioning of the belt relative to the platform may be, for example, between 1 mm and 5 cm to be considered safe. In other cases, to limit shear forces due to relative speed mismatch between the patient and the transfer process (e.g., the platform inserting under the patient), the belt should not "drift" beyond a range of approximately 1 mm to 10 mm to ensure that the patient does not experience a pushing sensation. In some cases, determining that no error exists (842) causes the manager system to coordinate with the transport controller 321 to continue control of the conveyor belt and the platform. In some cases, the manager system determines that there is a displacement error (842). In such a case, the manager system may conclude that a material obstruction has occurred (843), and in some cases cause the obstruction to be reported and / or cause instructions for next steps to be taken to be requested (844). In some implementations, subroutine 800D can be executed by the transport controller 321.

[0170] 8E is a flow diagram of a method 800E for adjusting the position of an object on a transport device according to various implementations. The method 800E includes subroutines or autonomous operations that the manager system can execute to adjust (800E) the location of an object, such as a patient, without the need for an imaging device such as a camera. In step 851, the manager system adjusts the subsystem controller 120 to transfer the object toward the center of the transport device. In steps 852 and 853, the manager system collects multiple sensor data from the subsystem controller 120 to monitor and compare the platform position and the object position, respectively. In step 854, the manager system uses the information from steps 852 and 853 to calculate the trajectory of the object and predict the final position of the object within the three sections of the device.

[0171] In step 855, the manager system adjusts the subsystem controller 120 to correct the transfer platform and conveyor belt kinematics according to the predicted final position from step 854. For example, assuming the patient 10 position starts anywhere in the platform 202, as shown in step 860 of FIG. 8F, if the predicted final position is in the middle section 82 of the transfer device 200, as shown in step 861 of FIG. 8F, the transfer process continues to move the patient 10 to the center of the platform 202 without interruption. As another example, if the predicted final position is in the first section 81 of the transfer device 200, which is closest to the original patient 10 location, as shown in step 862 of FIG. 8F, the manager system signals the transfer controller 321 to continue to move the platform to the center of the transfer device 200 and to move the conveyor belt to adjust the patient position to the center of the platform 202 and the transfer device 200, thus moving the patient 10 away from the device edge. As another example, if the predicted final position is at the third section 83 of the transport device 202, which is the furthest from the original patient 10 location, the manager system signals the transport controller 321 to perform a zero relative velocity for the transport device 200, thus maintaining the position of the patient 10 at the center of the device while moving the platform to the center under the object, as shown in step 863 of FIG. 8F, and preventing the patient 10 from moving too close to the edge of the transport device 200. In some implementations, the manager system can also signal the lift and tilt controller 322 to adjust the height and angle of the transport device 200 to help adjust the angle of approach and compression on the support surface to minimize elevation changes and any blunt force impacts on the patient 10. This in turn improves efficiency, comfort, and reduces the possibility of injury caused during the transport process.

[0172] According to various implementations, the transport device 200 and / or the distributed control system 100 may include one or more of the following aspects and features.

[0173] In some implementations, the distributed control system 100 can use logical data input and decision-making capabilities to eliminate the variability of user interaction and interpretation, enabling the transport device to accomplish patient transport easily and automatically.

[0174] In some implementations, the distributed control system 100 enables automatic and semi-autonomous operation. The transport device 200 can be controlled by various control subsystems that work together to perform patient transport without the need for user intervention.

[0175] In some implementations, the distributed control system 100 enables ease of use. A simple and efficient user interface can enable an operator to easily adjust the transfer platform and execute a patient transfer.

[0176] In some implementations, the distributed control system 100 enables basic operations including height adjustment (up / down), angle adjustment (tilt left up / down, tilt right up / down, tilt forward up / down), pick up from left, pick up from right, drop off left, and drop off right.

[0177] In some implementations, the distributed control system 100 enables safety and reliability. For example, in some cases, the distributed control system can automatically stop unsafe procedures or transfers that could potentially harm the patient or user, and will not begin the transfer process if the patient or transfer device is not in the proper position.

[0178] In some implementations, the distributed control system 100 allows for high system uptime (i.e., it does not fail frequently). If a fault or failure occurs within the control system, the patient is not harmed and the entire system does not go down.

[0179] In some implementations, the distributed control system 100 allows for adaptability such that patient transfer of any patient is possible regardless of the patient's size (i.e., weight and / or height). Patients can be picked up from and dropped off onto any patient support surface (e.g., bed, stretcher) regardless of height, stiffness, or surface material.

[0180] In some implementations, the distributed control system 100 allows for fault monitoring and redundancy. By utilizing multiple MCUs, the system has built-in fault tolerance. If a single MCU fails, the entire system has the ability to monitor communications and determine if a single controller has failed or if the entire system is down. Also, by distributing the processing and decision-making of the system, the probability of errors in each subsystem can be reduced by making firmware more manageable and unit testing of the subsystems more efficient than if everything was managed by one core MCU.

[0181] Numerous modifications and variations of the present disclosure are possible in light of the above teachings, and it is therefore to be understood that, within the scope of the appended claims, the present disclosure may be practiced otherwise than as specifically described herein.

Claims

1. A transport device, The device itself, A transfer platform supported by the device body, wherein the transfer platform comprises at least one conveyor belt configured to move objects on and / or off the transfer platform, Multiple subsystems, each subsystem configured to perform the functions of the transport device, A plurality of subsystem controllers, each subsystem controller configured to control the operation of one of the plurality of subsystems, at least two of the plurality of subsystem controllers located in different regions of the transport device near the components of the subsystem controlled by the subsystem controllers, and a transport subsystem controller configured to control at least the movement of the transport platform, A system processor that communicates with the plurality of subsystem controllers, wherein the system processor is The system monitors the plurality of subsystem controllers and communicates with the plurality of subsystem controllers. Receive operator input from the transport device operator, Based on the input received from the transport device operator and the input received from the multiple subsystem controllers, decisions regarding the transport operation are made. A transport device comprising a system processor configured to send commands to the aforementioned plurality of subsystem controllers.

2. The transport device according to claim 1, wherein the system processor and the plurality of subsystem controllers are configured to work together to automatically transport a patient without user intervention.

3. The transport device according to claim 1, wherein the system processor is configured to control the human-machine interface (HMI) of the transport device.

4. The transport device according to claim 1, wherein the transport subsystem controller is configured to receive the tension and displacement of the at least one conveyor belt, along with the location and speed of the transport platform for use in transporting a patient.

5. The transport device according to claim 1, wherein the plurality of subsystem controllers include subsystem controllers configured to adjust the height and angle of the transport platform and / or the transport of the transport device.

6. The transport device according to claim 1, wherein the plurality of subsystem controllers include subsystem controllers configured to control one or more peripheral subsystems of the transport device that are not involved in the movement of the transport platform.

7. The transport device according to claim 1, wherein the plurality of subsystem controllers comprises subsystem controllers configured to control the power supply to the electronic components of the transport device, including the system processor and the plurality of subsystem controllers, and to the actuators of the transport device.

8. The transport device according to claim 1, wherein the plurality of subsystems are configured to perform one or more of the following: (i) transporting an object; (ii) adjusting the height and angle of the transport platform and / or transporting the transport device; (iii) controlling peripheral equipment of the transport device that is not involved in the movement of the transport platform; (iv) providing device security; and (v) controlling the power supply to the electronic components of the distributed control system and to the actuators of the transport device.

9. The transport device according to claim 1, wherein the system processor is configured to establish a secure connection to an external network for uploading captured images, diagnostic data, and / or downloading firmware changes.

10. The transport device according to claim 9, wherein the external network is an intranet configured to support communication between multiple transport devices.

11. The transport device according to claim 9, wherein the external network is the World Wide Web.

12. The transport device according to claim 1, wherein the system processor communicates with an imaging subsystem comprising at least one imaging device, the system processor is configured to receive at least one captured image from the at least one imaging device, and to determine the at least one variable using image processing of the captured image such that at least one variable relates to the transport of an object by the transport device.

13. The transport device according to claim 12, wherein the system processor is configured to receive a plurality of captured images from the at least one imaging device that form a video feed, and to determine the at least one variable using image processing of the video feed such that at least one variable is related to the transport of an object by the transport device.

14. The transport device according to claim 12, wherein the subsystem controller is configured to determine the at least one variable using processing of the at least one captured image such that at least one variable is related to the transport of an object by the transport device.

15. The transfer device according to claim 14, wherein the at least one variable includes the mass and / or volume of the object.

16. The transfer device according to claim 14, wherein the at least one variable includes the position and / or orientation of the object.

17. The transport device according to claim 14, wherein the system processor is configured to evaluate the risk of damage to the object based on the at least one variable.

18. The transport device according to claim 14, wherein the system processor is configured to determine parameters and / or limitations for the transport device to transport the object based on the at least one variable.

19. The transport device according to claim 18, wherein the system processor receives feedback from at least one of the subsystem controllers regarding forces measured during the transport of the object, and the system processor is configured to adjust the parameters and / or limits in accordance with the feedback.

20. The transport device according to claim 13, wherein the system processor is connected to persistent memory configured to record the video feed for future playback.

21. The transport device according to claim 13, wherein the system processor is configured to establish an external data connection and to transmit the video feed to an external receiving unit via the external data connection for monitoring and observation.

22. A method for executing a transport device by a system processor, wherein the transport device comprises a device body and a transport platform configured to move an object, and the method is Receiving at least one image from at least one imaging device, A method comprising determining the at least one variable using image processing of the at least one image such that at least one variable is related to the transport of an object by the transport platform.

23. The method according to claim 22, wherein the at least one variable includes the mass and / or volume of the object.

24. The method according to claim 22, wherein the at least one variable includes the position and / or orientation of the object.

25. The method according to claim 22, further comprising evaluating the risk of damage to the object based on the determined at least one variable.

26. The method according to claim 22, further comprising determining parameters and / or limitations for the transport device to transport the object based on the determined at least one variable.

27. Receiving feedback regarding the force measured during the transport of the object, The method according to claim 26, further comprising adjusting the parameters and / or limits in accordance with the aforementioned feedback.

28. The method according to claim 22, further comprising recording the at least one image for future playback.

29. Establishing an external data connection, The method according to claim 22, further comprising transmitting the at least one image to an external receiving unit via the external data connection for monitoring and observation.

30. A non-temporary computer-readable medium on which statements and instructions are recorded that, when executed by the system processor of a transport device, constitute the system processor to carry out the method described in claim 22.

Images