User control device for a transporter

A user control device for a transporter. The user control device can communicate with the transporter via electrical interface(s) that can facilitate communication and data processing among the user interface device and controllers that can control the movement of the transporter. The user control device can perform automated actions based on the environment in which the transporter operates and the user's desired movement of the transporter. External applications can enable monitoring and control of the transporter.

BACKGROUND

The present teachings relate generally to personal vehicles, and more specifically to user control devices for vehicles that have heightened requirements for safety and reliability. Currently, personal vehicles can ascend and descend stairs. Such devices can include a plurality of wheels that can rotate about axes that are fixed with respect to a cluster arm. The cluster arm can rotate about an axis so that wheels rest on successive stairs. Currently, a user can board or disembark from an automobile or other enclosed vehicle and can load a personal vehicle into or out of the enclosed vehicle.

What is needed is a user control device that can automatically determine locations of key features of the environment of the personal vehicle and can automatically cause the personal vehicle to react to the key features.

SUMMARY

The user control device of the present teachings can include, but is not limited to including, a user control processor (UCP) assist that can provide enhanced functionality to a user of a personal vehicle such as the transporter of the present teachings, for example, but not limited to, assisting a user of the transporter in avoiding obstacles, traversing doors, traversing stairs, traveling on elevators, and parking/transporting the transporter. The UCP assist can receive user input and/or input from power base processors (PBPs) that can control the transporter, and can enable the invocation of a processing mode that has been automatically or manually selected. A command processor can enable the invoked mode by generating movement commands based at least on previous movement commands, data from the user, and data from sensors. The command processor can receive user data that can include signals from a joystick that can provide an indication of a desired movement direction and speed of the transporter. User data can also include mode selections into which the transporter could be transitioned. Modes such as door mode, rest room mode, enhanced stair mode, elevator mode, mobile storage mode, and static storage/charging mode can be selected. Any of these modes can include a move-to-position mode, or the user can direct the transporter to move to a certain position. UCP assist can generate commands such as movement commands that can include, but are not limited to including, speed and direction, and the movement commands can be provided to the PBPs which can transmit this information to wheel motor drives and cluster motor drives.

Sensor data can be collected by sensor-handling processors that can include, but are not limited to including, a transporter geometry processor, a point cloud library (PCL) processor, a simultaneous location and mapping (SLAM) processor, and an obstacle processor. The movement commands can also be provided to the sensor handling processors. The sensors can provide environmental information that can include, for example, but not limited to, obstacles and geometric information about the transporter. The sensors can include at least one time-of-flight sensor that can be mounted anywhere on transporter. There can be multiple sensors mounted on the transporter. The PCL processor can gather and process environmental information, and can produce PCL data that can be processed by a PCL library.

The transporter geometry processor of the present teachings can receive transporter geometry information from the sensors, can perform any processing necessary to prepare the transporter geometry information for use by the mode-dependent processors, and can provide the transporter geometry information to mode-dependent processors. The geometry of the transporter can be used for automatically determining whether or not the transporter can fit in and/or through a space such as, for example, a stairway and a door. The SLAM processor can determine navigation information based on, for example, but not limited to, user information, environmental information, and movement commands. The transporter can travel in a path at least in part set out by navigation information. An obstacle processor can locate obstacles and distances to the obstacles. Obstacles can include, but are not limited to including, doors, stairs, automobiles, and miscellaneous features in the vicinity of the path of the transporter.

The method for obstacle processing of the present teachings can include, but is not limited to including, receiving movement commands and user information, receiving and segmenting PCL data, identifying at least one plane within the segmented PCL data, and identifying at least one obstacle within the at least one plane. The method for obstacle processing can further include determining at least one situation identifier based at least on the obstacles, user information, and movement commands, and determining the distance between the transporter and the obstacles based at least on the situation identifier. The method for obstacle processing can also include accessing at least one allowed command related to the distance, the obstacle, and the situation identifier. The method for obstacle processing can still further include accessing an automatic response to the allowed command, mapping the movement command with one of the allowed commands, and providing the movement command and the automatic response associated with the mapped allowed command to the mode-dependent processors.

The obstacles can be stationary or moving. The distance can include a fixed amount and/or can be a dynamically-varying amount. The movement command can include, but is not limited to including, a follow command, a pass-the-obstacle command, a travel-beside-the-obstacle command, and a do-not-follow-the-obstacle command. The obstacle data can be stored and retrieved locally and/or in a cloud-based storage area, for example. The method can optionally include storing the obstacle data and allowing access to the stored obstacle data by systems external to the transporter. The method for obstacle processing can optionally include collecting sensor data from a time-of-flight camera mounted on the transporter, analyzing the sensor data using a point cloud library (PCL), tracking the moving object using SLAM based on the location of the transporter, identifying a plane within the obstacle data using, and providing the automatic response associated with the mapped allowed command to the mode-dependent processors. The method for obstacle processing can optionally receive a resume command, and provide, following the resume command, a movement command and the automatic response associated with the mapped allowed command to the mode-dependent processors. The automatic response can include a speed control command.

The obstacle processor of the present teachings can include, but is not limited to including, a nav/PCL data processor. The nav/PCL processor can receive the movement commands and the user information, and can receive and segment PCL data from a PCL processor, identify a plane within the segmented PCL data, and identify obstacles within the plane. The obstacle processor can include a distance processor. The distance processor can determine a situation identifier based on user information, the movement command, and the obstacles. The distance processor can determine the distance between the transporter and the obstacles based at least on the situation identifier. The moving object processor and/or the stationary object processor can access the allowed command related to the distance, the obstacles, and the situation identifier. The moving object processor and/or the stationary object processor can access an automatic response from an automatic response list associated with the allowed command. The moving object processor and/or the stationary object processor can access the movement command and map the movement command with one of the allowed commands. The moving object processor and/or stationary object processor can provide movement commands and the automatic response associated with the mapped allowed command to the mode-dependent processors. The movement command can include a follow command, a pass command, a travel-beside command, a move-to-position command, and a do-not-follow command. The nav/PCL processor can store obstacles in local storage and/or on storage cloud, and can allow access to the stored obstacles by systems external to the transporter.

The method of the present teachings for navigating stairs can include, but is not limited to including, receiving a stair command, and receiving environmental information from sensors mounted on the transporter and/or the obstacle processor. The method for navigating stairs can include locating, based on the environmental information, staircases within environmental information, and receiving a selection of one of the staircases located by the sensors and/or the obstacle processor. The method for navigating stairs can also include measuring the characteristics of the selected staircase, and locating, based on the environmental information, obstacles, if any, on the selected staircase. The method for navigating stairs can also include locating, based on the environmental information, a last stair of the selected staircase, and providing movement commands to move the transporter on the selected staircase based on the measured characteristics, the last stair, and the obstacles, if any. The method for navigating stairs can continue providing movement commands until the last stair is reached. The characteristics can include, but are not limited to including, the height of the stair riser of the selected staircase, the surface texture of the riser, and the surface temperature of the riser. Alerts can be generated if the surface temperature falls outside of a threshold range and the surface texture falls outside of a traction set.

The method can optionally include locating the at least one staircase based on GPS data, building a map of the selected staircase using SLAM, saving the map, and updating the map while the transporter is moving. The method can optionally include accessing a geometry of the transporter, comparing the geometry to the at least one characteristic of the selected staircase, and modifying the movement of the transporter based on the comparing step. The characteristic can include, but is not limited to including, the height of at least one riser of the selected staircase, the surface texture of the at least one riser, and the surface temperature of the at least one riser. The method can optionally include generating an alert if the surface temperature falls outside of a threshold range and the surface texture falls outside of a traction set. The threshold range can include, but is not limited to including, temperatures below 33° F. The traction set can include, but is not limited to including, a carpet texture. The method can optionally include determining, based on the sensor data, the topography of an area surrounding the selected staircase, and generating an alert if the topography is not flat. The method can optionally include accessing a set of extreme circumstances.

The navigating stair processor of the present teachings can include, but is not limited to including, a staircase processor receiving at least one stair command included in user information, and a staircase locator receiving, through, for example, the obstacle processor, environmental information from sensors mounted on the transporter. The staircase locator can locate, based on environmental information, the staircases within the environmental information, and can receive the choice of a selected staircase. The stair characteristics processor can measure the characteristics of the selected staircase, and can locate, based on environmental information, obstacles, if any, on the selected staircase. The stair movement processor can locate, based on environmental information, a last stair of the selected staircase, and can provide to movement processor movement commands to instruct the transporter to move on the selected staircase based on the characteristics, the last stair, and the obstacles, if any. The staircase locator can locate staircases based on GPS data, and can build and save a map of the selected staircase. The map can be saved for use locally and/or by other devices unrelated to the transporter. The staircase processor can access the geometry of the transporter, compare the geometry to the characteristics of the selected staircase, and modify the navigation of the transporter based on the comparison. The staircase processor can optionally generate an alert if the surface temperature of the risers of the selected staircase falls outside of a threshold range and the surface texture of selected staircase falls outside of a traction set. The stair movement processor can determine, based on the environmental information, the topography of an area surrounding the selected staircase, and can generate an alert if the topography is not flat. The stair movement processor can access a set of extreme circumstances that can be used to modify the movement commands generated by the stair movement processor.

When the transporter traverses the threshold of a door, where the door can include a door swing, a hinge location, and a doorway, the method of the present teachings for navigating a door can include receiving and segmenting environmental information from sensors mounted on the transporter. The environmental information can include the geometry of the transporter. The method can include identifying a plane within the segmented sensor data, and identifying the door within the plane. The method for navigating a door can include measuring the door based on the environmental information. The method for navigating a door can include determining the door swing and providing movement commands to move the transporter for access to a handle of the door. The method for navigating a door can include providing movement commands to move the transporter away from the door as the door opens by a distance based on the door measurements. The method for navigating a door can include providing movement commands to move the transporter forward through the doorway. The transporter can maintain the door in an open position if the door swing is towards the transporter.

The method of the present teachings for processing sensor data can determine, through information from the sensors, the hinge side of the door, the direction and angle of the door, and the distance to the door. The movement processor of the present teachings can generate commands to PBPs such as start/stop turning left, start/stop turning right, start/stop moving forward, start/stop moving backwards, and can facilitate door mode by stopping the transporter, cancelling the goal that the transporter can be aiming to complete, and centering the joystick. The door processor of the present teachings can determine whether the door is, for example, a push to open, a pull to open, or a slider. The door processor can determine the width of the door based on the current position and orientation of the transporter, and can determine the x/y/z location of the door pivot point. If the door processor determines that the number of valid points in the image of the door derived from the set of obstacles and/or PCL data is greater than a threshold, the door processor can determine the distance from the transporter to the door. The door processor can determine if the door is moving based on successive samples of PCL data from the sensor processor. In some configurations, the door processor can assume that a side of the transporter is even with the handle side of the door, and can use that assumption, along with the position of the door pivot point, to determine the width of the door. The door processor can generate commands to move the transporter through the door based on the swing and the width of the door. The transporter itself can maintain the door in an open state while the transporter traverses the threshold of the door.

In some configurations, the transporter can automatically negotiate the use of rest room facilities. The doors to the rest room and to the rest room stall can be located as discussed herein, and the transporter can be moved to locations with respect to the doors as discussed herein. Fixtures in the rest room can be located as obstacles as discussed herein, and the transporter can be automatically positioned in the vicinity of the fixtures to provide the user with access to, for example, the toilet, the sink, and the changing table. The transporter can be automatically navigated to exit the rest room stall and the rest room through door and obstacle processing discussed herein. The transporter can automatically traverse the threshold of the door based on the geometry of the transporter.

The method of the present teachings for automatically storing the transporter in a vehicle, such as, for example, but not limited to, an accessible van, can assist a user in independent use of the vehicle. When the user exits the transporter and enters the vehicle, possibly as the vehicle's driver, the transporter can remain parked outside of the vehicle. If the transporter is to accompany the user in the vehicle for later use, the mobile park mode of the present teachings can provide movement commands to the transporter to cause the transporter to store itself either automatically or upon command, and to be recalled to the door of the vehicle as well. The transporter can be commanded to store itself through commands received from external applications, for example. In some configurations, a computer-driven device such as a cell phone, laptop, and/or tablet can be used to execute one or more external applications and generate information that could ultimately control the transporter. In some configurations, the transporter can automatically proceed to mobile park mode after the user exits the transporter. Movement commands can include commands to locate the door of the vehicle at which the transporter will enter to be stored, and commands to direct the transporter to the vehicle door. Mobile park mode can determine error conditions such as, for example, but not limited to, if the vehicle door is too small for the transporter to enter, and mobile park mode can alert the user of the error condition through, for example, but not limited to, an audio alert through audio interface and/or a message to one or more external applications. If the vehicle door is wide enough for the transporter to enter, mobile park mode can provide vehicle control commands to command the vehicle to open the vehicle door. Mobile park mode can determine when the vehicle door is open and whether or not there is space for the transporter to be stored. Mobile park mode can invoke the method for obstacle processing to assist in determining the status of the vehicle door and if there is room in the vehicle to store the transporter. If there is enough room for the transporter, mobile park mode can provide movement commands to move the transporter into the storage space in the vehicle. Vehicle control commands can be provided to command the vehicle to lock the transporter into place, and to close the vehicle door. When the transporter is again needed, one or more external applications, for example, can be used to bring the transporter back to the user. The status of the transporter can be recalled, and vehicle control commands can command the vehicle to unlock the transporter and open the door of the vehicle. The vehicle door can be located and the transporter can be moved through the vehicle door and to the passenger door to which it had been summoned by, for example, one or more external applications. In some configurations, the vehicle can be tagged in places such as, for example, the vehicle entry door where the transporter can be stored.

The method of the present teachings for storing/recharging the transporter can assist the user in storing and possibly recharging the transporter, possibly when the user is sleeping. After the user exits the transporter, commands can be initiated by one or more external applications, to move the perhaps riderless transporter to a storage/docking area. In some configurations, a mode selection by the user while the user occupies the transporter can initiate automatic storage/docking functions after the user has exited the transporter. When the transporter is again needed, commands can be initiated by one or more external applications to recall the transporter to the user. The method for storing/recharging the transporter can include, but is not limited to including, locating at least one storage/charging area, and providing at least one movement command to move the transporter from a first location to the storage/charging area. The method for storing/recharging the transporter can include locating a charging dock in the storage/charging area and providing at least one movement command to couple the transporter with the charging dock. The method for storing/recharging the transporter can optionally include providing at least one movement command to move the transporter to the first location when the transporter receives an invocation command. If there is no storage/charging area, or if there is no charging dock, or if the transporter cannot couple with the charging dock, the method for storing/recharging the transporter can optionally include providing at least one alert to the user, and providing at least one movement command to move the transporter to the first location.

The method of the present teachings for negotiating an elevator while maneuvering the transporter can assist a user in getting on and off the elevator in the transporter. When the elevator is, for example, automatically located, and when the user selects the desired elevator direction, and when the elevator arrives and the door opens, movement commands can be provided to move the transporter into the elevator. The geometry of the elevator can be determined and movement commands can be provided to move the transporter into a location that makes it possible for the user to select a desired activity from the elevator selection panel. The location of the transporter can also be appropriate for exiting the elevator. When the elevator door opens, movement commands can be provided to move the transporter to fully exit the elevator.

DETAILED DESCRIPTION

The configuration of a user control device of the present teachings is discussed in detail below in relation to a transporter, for example, but not limited to, a wheelchair. Various types of transporters can interface with the user control device. The user control device can communicate with the transporter via electrical interface(s) that can facilitate communication and data processing among the user interface device and controllers that can control the movement of the transporter. The user control device can perform automated actions based on the environment in which the transporter operates and the user's desired movement of the transporter. External applications can enable monitoring and control of the transporter.

Referring now toFIG. 1, transporter120can include, but is not limited to including, user control device131, seat105, chassis104, power base160, first wheels101, second wheels102, third wheels103, and cluster121. UCD131can receive user and sensor input and can provide that information to power base160. UCD131can include, but is not limited to including, UCP130and UCP assist145. UCP assist can also be located independently from UCP130, and can be positioned anywhere on transporter120including, but not limited to, on the side and on the back of transporter120. Power base160can control, for example, the movements of wheels101and102, cluster121, and seat105based on inputs from UCD131and other factors including, but not limited to, automated enforcement of requirements for, for example, safety and reliability.

Continuing to refer toFIG. 1, transporter120can operate in functional modes such as, for example, but not limited to, standard mode201(FIG. 3A) in which transporter120can operate on drive wheels101and caster wheels103, and enhanced mode217(FIG. 3A) in which transporter120can operate on drive wheels101/102, can be dynamically stabilized through onboard sensors, and can operate having elevated chassis104, casters103, and seat105. Transporter120can also operate in balance mode219(FIG. 3A) in which transporter120can operate on drive wheels102, can have an elevated height of seat105, and can be dynamically stabilized through onboard sensors. Transporter120can further operate in stair mode215(FIG. 3A) in which transporter120can use wheel clusters121(FIG. 1) to climb and descend stairs and can be dynamically stabilized. Transporter120can still further operate in remote mode205(FIG. 3A) in which transporter120can operate on drive wheels101/102and can be unoccupied. Transporter120can optionally operate in docking mode203(FIG. 3A) in which transporter120can operate on drive wheels101/102and caster wheels103, thereby lowering chassis104. Some of the modes of transporter120are described in U.S. Pat. No. 6,343,664, entitled Operating Modes for Stair Climbing in Cluster-wheel Vehicle, issued Feb. 2, 2002, which is incorporated herein by reference.

Referring now primarily toFIGS. 2A-2D, power base160(FIG. 1) can include, but is not limited to including, at least one processor43A-43D (FIGS. 2C/2D), at least one motor drive1050,19,21,25,27,31,33,37(FIGS. 2C/2D), at least one inertial system1070,23,29,35(FIGS. 2C/2D), and at least one power source controller11A/B (FIG. 2B). Power base160(FIG. 1) can be communicatively coupled with, for example, but not limited to, UCD131(FIG. 2A) through, for example, but not limited to, electronic communications means53C and a protocol such as, for example, a controller area network (CAN) bus protocol. UCD131(FIG. 2A) can be optionally communicatively coupled with electronic devices140A (FIG. 2A) such as, for example, but not limited to, computers such as tablets and personal computers, telephones, and lighting systems, and can possibly be executing external applications140(FIG. 4). UCD131(FIG. 2A) can include, but is not limited to including, at least one manual interface such as, for example, joystick133(FIG. 5B) and at least one push button141A/B/C (FIG. 6), at least one visual interface such as, for example, display (FIG. 5A), and, optionally, at least one UCP assist145(FIG. 4). UCD131(FIG. 2A) can optionally be communicatively coupled with peripheral control module1144, sensor aid modules1141, and autonomous control modules1142/1143. Communications can be enabled by, for example, but not limited to, a CANbus protocol and an Ethernet protocol. Other protocols can be used.

Continuing to refer primarily toFIGS. 2A-2D, in some configurations, each at least one processor43A-43D (FIGS. 2C/2D) can include, but is not limited to including, at least one cluster motor drive1050,27(FIGS. 2C/2D), at least one right wheel motor drive19,31(FIG. 2C), at least one left wheel motor drive21,33(FIGS. 2C/2D), at least one seat motor drive25,37(FIGS. 2C/D), and at least one inertial sensor pack1070,23,29,35(FIGS. 2C/2D). Power base160can further include at least one cluster brake57,69(FIGS. 2C/2D), at least one cluster motor83,89(FIGS. 2C/2D), at least one right wheel brake59,73(FIG. 2C/2D), at least one left wheel brake63,77(FIGS. 2C/2D), at least one right wheel motor85,91(FIGS. 2C/2D), at least one left wheel motor87,93(FIGS. 2C/2D), at least one seat motor45,47(FIGS. 2C/2D), at least one seat brake65,79(FIGS. 2C/2D), at least one cluster position sensor55,71(FIGS. 2C/2D), and at least one manual brake release61,75(FIGS. 2C/2D).

Continuing to refer primarily toFIGS. 2A-2D, power base160(FIG. 2C) can be used to drive cluster121(FIG. 1) of wheels101/102(FIG. 1) forming a ground-contacting module. The ground-contacting module can be mounted on cluster121(FIG. 1), and each wheel101/102(FIG. 1) of the ground-contacting module can be driven by a wheel motor drive such as, for example, right wheel motor drive A19(FIG. 2C), or redundant right wheel motor drive B31(FIG. 2D). Cluster121(FIG. 1) can rotate about a cluster axis, the rotation being governed by, for example, cluster motor drive A1050(FIG. 2C), or redundant cluster motor drive B27(FIG. 2D). At least one of the sensors such as, for example, but not limited to, at least one cluster position sensor55/71(FIGS. 2C/2D), at least one manual brake release sensor61/75(FIGS. 2C/2D), at least one motor current sensor (not shown), and at least one inertial sensor pack17,23,29,35(FIGS. 2C/2D) can sense the state of transporter120(FIG. 1).

Continuing to still further refer toFIGS. 2A-2D, processors43A-43D (FIGS. 2C/2D) can be electronically coupled to UCD131(FIG. 2A) for receiving control input, as well as to other controllers for controlling peripheral and extraordinary functions of transporter120(FIG. 1). Communications53A-53C (FIG. 2B) among UCD131(FIG. 2A), power source controllers11A/11B (FIG. 2B), and each of processors43A-43D (FIGS. 2C/D) can be according to any protocol including, but not limited to, a CANbus protocol. At least one Vbus95,97(FIG. 2B) can connect at least power source controller11A/B (FIG. 2B) to power base160(FIG. 2C) and components external to power base160(FIG. 2C) through external Vbus107(FIG. 2B). In some configurations, processor A143A (FIG. 2C) can be the master of CANbus A53A (FIG. 2B). Slaves on CANbus A53A (FIG. 2B) can be processor A243B (FIG. 2C), processor B143C (FIG. 2D), and processor B243D (FIG. 2D). In some configurations, processor B143C (FIG. 2D) can be the master of CANbus B53B (FIG. 2B). Slaves on CANbus B53B (FIG. 2B) can be processor B243C (FIG. 2D), processor A143A (FIG. 2C), and processor A243B (FIG. 2C). UCD131(FIG. 2A) can be the master of CANbus C53C (FIG. 2B). Slaves on CANbus C53C (FIG. 2B) can be power source controller11A/B (FIG. 2B), processor A143A (FIG. 2C), processor A243B (FIG. 2C), processor B143C (FIG. 2D), and processor B243D (FIG. 2D). The master node (any of processors43A-43D (FIG. 2C/D) or UCD131(FIG. 2A)) can send data to or request data from the slaves.

Referring now primarily toFIGS. 2C/2D, in some configurations, power base160can include redundant processor sets A/B39/41that can control clusters121(FIG. 1) and rotating drive wheels101/102(FIG. 1). Right/left wheel motor drives A/B19/21,31/33can drive right/left wheel motors A/B85/87,91/93that drive wheels101/102(FIG. 1) on the right and left sides of transporter120(FIG. 1). Wheels101/102(FIG. 1) can be coupled to drive together. Turning can be accomplished by driving left wheel motors A/B87/93and right wheel motors A/B85/91at different rates. Cluster motor drive A/B1050/27can drive cluster motors A/B83/89that can rotate the wheel base in the fore/aft direction which can allow transporter120(FIG. 1) to remain level while front wheels101(FIG. 1) are higher or lower than rear wheels102(FIG. 1). Cluster motors A/B83/89can keep transporter120(FIG. 1) level when climbing up and down curbs, and can rotate the wheel base repeatedly to climb up and down stairs. Seat motor drive A/B25/37can drive seat motors A/B45/47that can raise and lower seat105(FIG. 1).

Continuing to further refer toFIGS. 2C/2D, cluster position sensors A/B55/71can sense the position of cluster121(FIG. 1) of wheels101/102(FIG. 1). The signals from cluster position sensors A/B55/71and seat position sensors A/B67/81can be communicated among processors43A-43D and can be used by processor set A/B39/41to determine signals to be sent to, for example, right wheel motor drive A/B19/31, cluster motor drive A/B15/27and seat motor drive A/B25/37. The independent control of clusters121(FIG. 1) and drive wheels101/102(FIG. 1) can allow transporter120(FIG. 1) to operate in several modes, thereby allowing processors43A-43D to switch between modes, for example, in response to the local terrain. The mode switch can occur, for example, automatically and/or at the request of a user.

Continuing to still further refer toFIGS. 2C/2D, inertial sensor packs1070,23,29,35can sense, for example, but not limited to, the orientation of transporter120(FIG. 1). Each processor43A-43D can include, in inertial sensor packs1070,23,29,35, accelerometers and gyroscopes. In some configurations, each inertial sensor pack1070,23,29,35can include, but is not limited to including, four sets of three-axis accelerometers and three-axis gyros. The accelerometer and gyro data can be fused on each of processors43A-43D. Each processor43A-43D can produce a gravity vector that can be used to compute the orientation and inertial rotation rates of power base160(FIG. 1). The fused data can be shared across processors43A-43D and can be subjected to threshold criteria. The threshold criteria can be used to improve the accuracy of device orientation and inertial rotation rates. For example, fused data from certain of processors43A-43D that exceed certain thresholds can be discarded. The fused data from each of processors43A-43D that are within pre-selected limits can be, for example, but not limited to, averaged or processed in any other form. Inertial sensor packs1070,23,29,35can include, but are not limited to including, sensors such as, for example, ST®microelectronics LSM330DLC, or any sensor supplying a 3D digital accelerometer and a 3D digital gyroscope, or further, any sensor that can measure gravity and body rates. Sensor data can be subject to processing, for example, but not limited to, filtering to improve control of transporter120(FIG. 1).

Continuing to still further refer primarily toFIGS. 2C/2D, power base160(FIG. 1) can include sensors such as, for example, but not limited to, ALLEGRO™ ACS709 current sensor IC, or any sensor that can sense at least a pre-selected number of motor currents, has bi-directional sensing, has user-selectable over-current fault setting, and can handle peak currents above a pre-selected fault limit. Cluster position sensors A/B55/71, seat position sensors A/B67/81, and manual brake release sensors A/B61/75can include but are not limited to including, Hall sensors.

Referring now primarily toFIG. 3A, in some configurations, power base processors100(FIG. 4) can support at least one operating mode, and active controller64A can enable navigation among modes. The at least one operating mode can include, but is not limited to including, standard mode201(described with respect toFIG. 1), enhanced mode217(described with respect toFIG. 1), balance mode219(described with respect toFIG. 1), stair mode215(described with respect toFIG. 1), docking mode203(described with respect toFIG. 1), and remote mode205(described with respect toFIG. 1). Service modes can include, but are not limited to including, recovery mode161, failsafe mode167(FIG. 3B), update mode169(FIG. 3B), self-test mode171(FIG. 3B), calibrate mode163, power on mode207(FIG. 3B), and power off mode209(FIG. 3B). With respect to recovery mode161, if a power off occurs when transporter120(FIG. 1) is not in one of a pre-selected set of modes, such as for example, but not limited to, standard mode201, docking mode203, or remote mode205, transporter120(FIG. 1) can enter recovery mode161to safely reposition transporter120(FIG. 1) into the driving position of standard mode201. During recovery mode161, power base processors100(FIG. 4) can select certain components to activate such as, for example, seat motor drive A/B25/37(FIG. 2C/2D) and cluster motor drive A/B1050/27(FIG. 2C/2D). Functionality can be limited to, for example, controlling the position of seat105(FIG. 1) and cluster121(FIG. 1).

Referring now primarily toFIG. 3B, transporter120(FIG. 1) can be transitioned into failsafe mode167when transporter120(FIG. 1) can no longer effectively operate. In failsafe mode167, at least some active operations can be halted to protect against potentially erroneous or uncontrolled motion. Transporter120(FIG. 1) can be transitioned from standard mode201(FIG. 3A) to update mode169to, for example, but not limited to, enable communications with external applications140(FIG. 4) that can be executing external to power base160(FIG. 1). Transporter120(FIG. 1) can be transitioned to self-test mode171when transporter120(FIG. 1) is first powered. In self-test mode171, electronics in power base160(FIG. 1) can perform self diagnostics and can synchronize with one another. In some configurations, system self-tests can be performed to check the integrity of systems that are not readily testable during normal operation, for example, memory integrity verification tests and disable circuitry tests. While in self-test mode171, operational functions can be disabled.

Referring now primarily toFIG. 4, transporter control system200A can include, but is not limited to including, at least one power base processor100and at least one power source controller11that can bi-directionally communicate over serial bus143with system serial bus messaging system130F. System serial bus messaging130F can bi-directionally communicate with I/O interface130G, external communications130D, UCP130, and UCP assist145. UCP130and UCP assist145can access peripherals, processors, and controllers through interface modules that can include, but are not limited to including, input/output (I/O) interface130G, system serial bus (SSB) messaging interface130F, and external communications interface130D. In some configurations, I/O interface130G can transmit/receive messages to/from, for example, but not limited to, at least one of audio interface150, electronic interface149, manual interface153, and visual interface151. Audio interface150can transmit data from, for example, UCP130to audio devices such as, for example, speakers that can project, for example, alerts when transporter120(FIG. 1) requires attention. Electronic interface149can transmit/receive messages to/from, for example, but not limited to, sensors147. Sensors147can include, but are not limited to including, time-of-flight cameras and other sensors. Manual interface153can transmit/receive messages to/from, for example, but not limited to, joystick133(FIG. 5B) and/or switches/buttons141/B/C (FIG. 6), and/or information lighting such as LED lights, and/or display137(FIG. 5A) having, for example, a touch screen. UCP130and UCP assist145can transmit/receive information to/from I/O interface130G, system serial bus messaging130F, external communications130D, and each other.

Continuing to refer primarily toFIG. 4, system serial bus interface130F can enable communications among UCP130, UCP assist145, power base processors (PBPs)100(also shown, for example, as processor A143A (FIG. 2C), processor A243B (FIG. 2C), processor B143C (FIG. 2D), and processor B243D (FIG. 2D)), and power source controllers11(also shown, for example, as power source controller A11A (FIG. 2B) and power source controller B11B (FIG. 2B)). Messages described herein can be exchanged among UCP130, UCP assist145, and PBPs100using, for example, but not limited to, system serial bus143. External communications interface130D can enable communications among, for example, UCP130, UCP assist145, and external applications140using wireless communications144such as, for example, but not limited to, BLUETOOTH® technology. UCP130and UCP assist145can transmit/receive messages to/from sensors147that can be used to enable automatic and/or semi-automatic control of transporter120(FIG. 1).

Referring now primarily toFIGS. 5A, 5B, and 6, switches and buttons141A/B/C (FIG. 6) associated with transporter120(FIG. 1) can generate, upon activation, signals to I/O interface130G (FIG. 4). The signals can be decoded and debounced by, for example, UCP130(FIG. 4) and/or PBPs100(FIG. 4). Examples of functions that can be enabled by switches/buttons141A/B/C (FIG. 6) can include, but are not limited to including, height of seat105(FIG. 1), lean of seat105(FIG. 1), mode selection, drive setting menu selection, disabling joystick133(FIG. 5B), selection confirmation, power off request, alarm status acknowledgement, and horn actuation. An alert, such as a flashing icon, can be provided to bring a condition to the attention of the user. The conditions can include, but are not limited to including, low battery, service required, temperature out of range, parking brake manually overridden that could be inhibiting a user-requested a power off, and a critical fault, warning, or alert. Switches/buttons141A/B/C (FIG. 6) can have functionality that is context-dependant and can have secondary functionality that occurs if, for example, switches/button141A/B/C (FIG. 6) are depressed for a certain period of time. Certain switches/buttons141A/B/C (FIG. 6) can be disabled if, for example, a mode change occurs and/or the battery charger is connected. When joystick133(FIG. 5B) is disabled, certain other functions can be disabled such as, for example, but not limited to, mode selection, drive menu selection, and adjustments to seat105(FIG. 1). Disabled switches/buttons141A/B/C (FIG. 6) can be re-enabled under certain conditions such as, for example, when associated switches/buttons141A/B/C (FIG. 6) are released. In some configurations, button141C (FIG. 6) can provide a way to indicate power on, and can also provide an indication of device status and/or a means to acknowledge device status. In some configurations, button141B (FIG. 6) can provide, for example, a hazard flasher and/or a power on flasher. In some configurations, button141A (FIG. 6) can provide a means to enable a horn and/or a confirmation of a selection.

Referring now primarily toFIG. 6A, UCD holder133A can house manual and visual interfaces such as, for example, joystick133(FIG. 5B), display137(FIG. 5A), and associated electronics. Connector133C (FIG.6B2) can allow connection to UCP assist145(FIG. 4). In some configurations, UCP assist holder145A can be attached to visual/manual interface holder145C tool-lessly. UCP assist holder145A can house UCP assist145that can include sensor147A (FIG. 12A). Sensor147A (FIG. 12A) can include, but is not limited to including, an OPT8241 time-of-flight sensor from TEXAS INSTRUMENTS®, or any device that can provide a three-dimensional location of the data sensed by sensor147A (FIG. 12A). UCP assist holder145A and connector133C (FIG.6B2) can be located anywhere on transporter120(FIG. 1) and may not be limited to being mounted on visual/manual interface holder145C.

Referring now primarily to FIGS.6B1and6B2, manual/visual interface holder145C can include, but is not limited to including, visual interface viewing window137A (FIG.6B1) and manual interface mounting cavity133B (FIG.6B1) available on first side133E (FIG.6B1) of manual/visual interface holder145C. Connector133C (FIG.6B2) can be provided on second side133D (FIG.6B2) of manual/visual interface holder145C. Any of viewing window137A (FIG.6B1), manual interface mounting cavity133B (FIG.6B1), and connector133C (FIG.6B2) can be located on any part of manual/visual interface holder145C, or can be absent altogether. Manual/visual interface holder145C, visual interface viewing window137A (FIG.6B1), manual interface mounting cavity133B (FIG.6B1), and connector133C (FIG.6B2) can be any size. Manual/visual interface holder145C can be constructed of any material suitable for mounting visual interface viewing window137A (FIG.6B1), manual interface mounting cavity133B (FIG.6B1), and connector133C (FIG.6B2). Angle145M can be associated with various orientations of UCD holder133A and thus can be various values. UCD holder133A can have a fixed orientation or can be hinged.

Referring now primarily to FIGS.6B3and6B4, UCP assist holder145A can include, but is not limited to including, filter cavity136G and lens cavity136F providing visibility to, for example, but not limited to, a time-of-flight sensor optical filter and lens such as, for example, but not limited to, OPT8241 3D time-of-flight sensor by TEXAS INSTRUMENTS®. UCP assist holder145A can be any shape and size and can be constructed of any material, depending on the mounting position on transporter120and the sensors, processors, and power supply, for example, provided within UCP assist holder145A. Rounded edges on cavities136G and136F, on casing136E, as well as on holder145A can be replaced by any shape of edge. Cavity136H can house controlling electronics.

Referring now primarily to FIGS.6C1and6C2, connector133C can include, but is not limited to including, connector lead133G (FIG.6C1) on connector first side133H (FIG.6C1) and connector pins133F that can protrude from connector second side133I (FIG.6C2). Connector lead133G (FIG.6C1) and connector pins133F can be any size and shape, and there can be any number of connector leads133G (FIG.6C1) and connector pins133F. Further, there can be any number of connectors133C.

Referring now primarily to FIGS.6D1and6D2, mounting board134J can include, but is not limited to including, pin holes134D, mounting holes134C, and alignment features134B. Mounting board first side134A can be identical to mounting board second side134E, or mounting board first side134A can have different features from mounting board second side134E. Mounting holes134C, pin holes134D, and alignment features134B can be any size and/or shape, and there can be any number of mounting holes134C, pin holes134D and alignment features134B. Mounting board134J can be used to mount connector133C (FIGS.6C1/6C2). In some configurations, mounting board134J can include pin holes134D that can accommodate connector pins133F (FIGS.6C1/6C2). Mounting board134J can be provided in multiple pieces and shapes to accommodate connector(s)133C (FIGS.6C1/6C2).

Referring now to FIGS.6D3and6D4, connector pins133F can be inserted into pin holes134D to mount connector133C on mounting board134J. Connector leads133G can project from mounting board first side134A (FIG.6D3), and connector pins133F can protrude from mounting board second side134E (FIG.6D4). Connector133C can be positioned anywhere on mounting board134J, and can cross multiple mounting boards134J. Multiple of connectors133C can be mounted on mounting board134J.

Referring now primarily to FIGS.6D5and6D6, in some configurations, second configuration connector139D can be mounted on mounting board134J (FIG.6D1) to mount UCP assist holder145A (FIG. 6A). Arched lead139A on second configuration connector first side139E can form cavity139B into which mated connectors (not shown) from UCP assist holder145A (FIG. 6A) can be inserted. Second configuration connector second side139F can include protruding of second configuration connector pins139C that can be inserted into mounting board134J (FIG.6D1).

Referring now primarily toFIG. 6E, transporter120(FIG. 1) can be fitted with any number of sensors147(FIG. 4) in any configuration. In some configurations, some of sensors147(FIG. 4) can be mounted on transporter rear122to accomplish specific goals, for example, backup safety. Stereo color cameras/illumination122A, ultrasonic beam range finder122B, time-of-flight cameras122D/122E, and single point LIDAR sensors122F can be mounted, for example, but not limited to, to cooperatively sense obstacles behind transporter120(FIG. 1). PBPs100(FIG. 4) and/or UCP assist145(FIG. 4) can receive messages that can include information from the cameras and sensors, and can enable transporter120(FIG. 1) to react to what might be happening out of the view of the user. Transporter120(FIG. 1) can also include reflectors122C that can be optionally fitted with further sensors. Stereo color cameras/illumination122A can also be used as taillights. Other types of cameras and sensors can be mounted on transporter120(FIG. 1). Information from the cameras and sensors can be used to enable a smooth transition to balance mode219(FIG. 3A) by providing information to UCP assist145(FIG. 4) to enable UCP assist145(FIG. 4) to locate any obstacles that might impeded the transition to balance mode219(FIG. 3A).

Referring now primarily toFIG. 7A, SSB143(FIG. 4) can provide communications through use of, for example, a CAN Bus protocol. Devices connected to SSB143(FIG. 4) can be programmed to respond/listen to specific messages received, processed, and transmitted by SSB messaging130F (FIG. 4). Messages can include packets, which can include, but are not limited to including, eight bytes of data and a CAN Bus device identification that can identify the source of the packet. Devices receiving CAN bus packets can ignore invalid CAN bus packets. When an invalid CAN bus packet is received, the received device can take alternative measures, depending on, for example, the current mode of transporter120(FIG. 1), the previous CAN bus messages, and the receiving device. The alternate measures can, for example, maintain stability of transporter120(FIG. 1). The bus master of SSB143(FIG. 4) can transmit master sync packet901to establish a bus alive sequence on a frame basis and synchronize the time base.

Referring now primarily toFIG. 7B, user control panel packet #1903(FIG. 7A) can include eight bytes and can have, for example, packet format701. Packet format701can include, but is not limited to including, status701A, error device identification701B, mode requested701C, control out byte701D, commanded velocity701E, commanded turn rate701F, seat control byte701G, and system data701H. Status701A can include, but is not limited to including, possibilities such as, for example, self test in progress, device okay, non-fatal device failure (data OK), and fatal device failure in which receiving devices can ignore the data in the packet. If UCP130, for example, receives a device failure status, UCP130can post an error to, for example, a graphical user interface (GUI) on display137(FIG. 5A). Error device ID701B can include the logical ID of the device for which received communications has been determined to be erroneous. Error device ID701B can be set to zero when no errors are received.

Referring now primarily toFIG. 7C, mode requested code701C (FIG. 7B) can be defined such that a single bit error may not indicate another valid mode. For example, mode codes can include, but are not limited to including, self-test, standard, enhanced, stair, balance, docking, remote, calibration, update, power off, power on, fail safe, recovery, flasher, door, mobile storage, static storage/charging, rest room, elevator, and enhanced stair, the meanings of which are discussed herein. Mode requested code701C can indicate if the mode being requested should be processed to (1) either maintain the current mode or execute an allowed mode change or (2) enable situation-dependent processing. In some configurations, special situations can require automatic control of transporter120(FIG. 1). For example, transporter120(FIG. 1) can transition from stair mode215(FIG. 3A) automatically to enhanced mode217(FIG. 3A) when transporter120(FIG. 1) has reached a top landing of a staircase. In some configurations, PBPs100(FIG. 4) and/or UCP assist145(FIG. 4) can, for example, but not limited to, modify the response of PBPs100(FIG. 4) to commands from joystick133(FIG. 1), for example, by setting transporter120(FIG. 1) to a particular mode. In some configurations, transporter120(FIG. 1) can automatically be set to a slow driving mode when transporter120(FIG. 1) is transitioned out of stair mode215(FIG. 3A). In some configurations, when transporter120(FIG. 1) transitions from stair mode215(FIG. 3A) automatically to enhanced mode217(FIG. 3A), joystick133(FIG. 1) can be disabled. When a mode is selected by any of UCP assist145(FIG. 4), UCP130(FIG. 4) through, for example, but not limited to, user entry, and/or PBPs100(FIG. 4), mode availability can be determined based at least in part on current operating conditions.

Continuing to refer primarily toFIG. 7C, in some configurations, if a transition is not allowed to a user-selected mode from the current mode, the user can be alerted. Certain modes and mode transitions can require user notification and possibly user assistance. For example, adjustments to seat105(FIG. 1) can be needed when positioning transporter120(FIG. 1) for a determination of the center of gravity of transporter120(FIG. 1) along with the load on transporter120(FIG. 1). The user can be prompted to perform specific operations based on the current mode and/or the mode to which the transition can occur. In some configurations, transporter120(FIG. 1) can be configured for, for example, but not limited to, fast, medium, medium dampened, or slow speed templates. The speed of transporter120(FIG. 1) can be modified by using, for example, speed template700(FIG. 8) relating output703(FIG. 8) (and wheel commands) to joystick displacement702(FIG. 8).

Referring now toFIG. 7D, control out byte701D (FIG. 7B) can include, but is not limited to including, bit definitions such as, for example, but not limited to, OK to power down801A, drive selection801B, emergency power off request801C, calibration state801D, mode restriction801E, user training801F, and joystick centered801G. In some configurations, OK to power down801A can be defined to be zero if power down is not currently allowed, and drive selection801B can be defined to specify motor drive1(bit6=0) or motor drive2(bit6=1). In some configurations, emergency power off request801C can be defined to indicate if an emergency power off request is normal (bit5=0), or an emergency power off request sequence is in process (bit5=1), and calibration state801D can be defined to indicate a request for user calibration (bit4=1). In some configurations, mode restriction801E can be defined to indicate whether or not there are restrictions for entering a particular mode. If the mode can be entered without restriction, bit3can be zero. If there are restrictions to entering a mode, for example, but not limited to, balance-critical modes can require certain restrictions to maintain the safety of the passenger of transporter120(FIG. 1), bit3can be one. User training801F can be defined to indicate if user training is possible (bit2=1), or not (bit2=0), and joystick centered801G can be defined to indicate if joystick133(FIG. 1) is centered (bits0-1=2), or not (bits0-1=1).

Referring again primarily toFIG. 7B, commanded velocity701E can be, for example, a value representing forward or reverse speed. Forward velocity can be a positive value and reverse velocity can be a negative value, for example. Commanded turn rate701F can be a value representing a left or right commanded turn rate. A left turn can be a positive value and a right turn can be a negative value. The value can represent the differential velocity between the left and right of wheels101/102(FIG. 1) equivalently scaled to commanded velocity701E.

Referring again primarily toFIG. 7D, joystick133(FIG. 1) can have multiple redundant hardware inputs. Signals such as, for example, commanded velocity701E (FIG. 7B), commanded turn rate701F (FIG. 7B), and joystick-centered801G can be received and processed. Commanded velocity701E (FIG. 7B) and commanded turn rate701F (FIG. 7B) can be determined from a first of the multiple hardware inputs, and joystick-centered801G can be determined from a second of the hardware inputs. Values of joystick-centered801G can indicate when a non-zero of commanded velocity701E (FIG. 7B) and a non-zero of commanded turn rate701F (FIG. 7B) are valid. Fault conditions for joystick133(FIG. 1) in, for example, the X and Y directions can be detected. For example, each axis of joystick133(FIG. 1) can be associated with dual sensors. Each sensor pair input (X (commanded velocity701E (FIG. 7B)) and Y (command turn rate701F (FIG. 7B)) can be associated with an independent A/D converter, each with a voltage reference channel check input. In some configurations, commanded velocity701E (FIG. 7B) and commanded turn rate701F (FIG. 7B) can be held to zero by the secondary input to avoid mismatch. If joystick-centered801G is within a minimum deadband, or joystick133(FIG. 1) is faulted, joystick133(FIG. 1) can be indicated as centered. A deadband can indicate the amount of displacement of joystick133(FIG. 1) that can occur before a non-zero output from joystick133(FIG. 1) can appear. The deadband range can set the zero reference region to include an electrical center position that can be, for example, but not limited to, 45% to 55% of the defined signal range.

Referring now primarily toFIG. 7E, seat control byte701G (FIG. 7B) can convey seat adjustment commands. Frame lean command921can include values such as, for example, invalid, lean forward, lean rearward, and idle. Seat height command923can include values such as, for example, invalid, lower seat down, raise seat up, and idle.

Referring again toFIG. 7A, user control packets905can include header, message ID, and data for messages traveling primarily to and from external applications140(FIG. 4) through, for example, but not limited to, a BLUETOOTH® connection. PBPs packet907can include data originated by PBPs100(FIG. 4) and destined for PSCs11(FIG. 4). PBP A143A (FIG. 2C), for example, can be designated the master of SSB143(FIG. 4), and PBP B143C (FIG. 2D), for example, can be designated as the secondary master of SSB143(FIG. 4) if PBP A143A (FIG. 2C) is no longer transmitting on the bus. The master of SSB143(FIG. 4) can transmit master sync packet901at a periodic rate, for example, but not limited to, every 20 ms+/−1%. Devices communicating using SSB143(FIG. 4) can synchronize the transmitting of messages to the beginning of master sync packet901.

Referring now primarily toFIG. 8, joystick133(FIG. 1) can be configured to have different transfer functions to be used under different conditions according to, for example, the abilities of the user. Speed template (transfer function)700shows an exemplary relationship between physical displacement702of joystick133(FIG. 1) and output703of joystick133(FIG. 1) after transfer function processing. Forward and reverse travel of joystick133(FIG. 1) can be interpreted as forward longitudinal requests and reverse longitudinal requests, respectively, as viewed from a user in seat105(FIG. 1), and can be equivalent to commanded velocity701E (FIG. 7), the X request value. Left and right travel of joystick133(FIG. 1) can be interpreted as left turn requests and right turn requests, respectively, as viewed from a user in seat105(FIG. 1), and can be equivalent to commanded turn rate701F, the Y request value. Joystick output703can be modified during certain conditions such as, for example, but not limited to, battery voltage conditions, height of seat105(FIG. 1), mode, failed conditions of joystick133(FIG. 1), and when speed modification is requested by PBPs100(FIG. 4). Joystick output703can be ignored and joystick133(FIG. 1) can be considered as centered, for example, but not limited to, when a mode change occurs, or while in update mode169(FIG. 3B), or when the battery charger is connected, or when in stair mode, or when joystick133(FIG. 1) is disabled, or under certain fault conditions.

Continuing to refer primarily toFIG. 8, transporter120(FIG. 1) can be configured to suit a particular user. In some configurations, transporter120(FIG. 1) can be tailored to user abilities, for example, by setting speed templates and mode restrictions. In some configurations, transporter120(FIG. 1) can receive commands from external applications140(FIG. 4) executing on devices such as, for example, but not limited to, a cell phone, a computer tablet, and a personal computer. The commands can provide, for example, default and/or dynamically-determinable settings for configuration parameters. In some configurations, a user and/or an attendant can configure transporter120(FIG. 1).

Referring now toFIG. 9, any of UCP130, UCP assist145, and/or PBPs100can execute a power up and processing sequence when UCP130(FIG. 4) and/or PBPs100(FIG. 4) and/or UCP assist145(FIG. 4) receive powered on indication1017. Power on processing1005can include, but is not limited to including, integrity checks that can be performed on, for example, stored data and various indicators. Memory tests can be performed, system and configuration parameters can be established in memory, and a readiness to operate can be indicated, for example, but not limited to, by lighted LEDs. Power on processing1005can be followed by transitioning to main loop processing1001in which sensor data1003can be received and processed, input messages1027can be received, and output messages1013can be generated periodically, for example, but not limited to, once every frame of SSB143(FIG. 4). Device data1009and communications information1011can be accessed. Device data1009can include, but is not limited to including, a device status that can, for example, display device diagnostic data. In some configurations, communications with external applications140(FIG. 4) can be provided to gather information such as, for example, but not limited to, application code version numbers, application code CRC values, and protocol map compatibility information. UCP130(FIG. 4), UCP assist145(FIG. 4), and/or PBPs100(FIG. 4) can execute a power down sequence upon receiving power off request1015. Ongoing activities such as, for example, but not limited to, data logging, and receiving data from, for example, switches/buttons141A/B/C (FIG. 6), and joysticks133(FIG. 1), can be disabled and brought to a consistent close. Configuration, usage, service, security, and other information can be accumulated and stored during power off processing1007.

Referring now toFIG. 10, UCP assist145can provide enhanced functionality to a user, for example, but not limited to, assisting a user in avoiding obstacles, traversing doors, traversing stairs, traveling on elevators, and parking/transporting transporter120(FIG. 1). In general, UCP assist145can receive user input (for example UI data633) and/or input from PBPs100(FIG. 4) through, for example, but not limited to, messages from user interface devices and sensors147. UCP assist145can further receive sensor input through, for example, but not limited to sensor processing systems661. UI data633and output from sensor processing systems661, for example, can inform command processor601to invoke the mode that has been automatically or manually selected. Command processor601can pass UI data633and output from sensor processing systems661to a processor that can enable the invoked mode. The processor can generate movement commands630at least based on previous movement commands630, UI data633, and output from sensor processing systems661.

Continuing to refer toFIG. 10, UCP assist145can include, but is not limited to including, command processor601, movement processor603, simultaneous location and mapping (SLAM) processor609, point cloud library (PCL) processor611, geometry processor613, and obstacle processor607. Command processor601can receive user interface (UI) data633from the message bus. UI data633can include, but is not limited to including, signals from, for example, joystick133(FIG. 1) providing an indication of a desired movement direction and speed of transporter120(FIG. 1). UI data633can also include selections such as an alternate mode into which transporter120(FIG. 1) could be transitioned. In some configurations, in addition to the modes described with respect toFIGS. 3A/3B, UCP assist145can process mode selections such as, but not limited to, door mode605A, rest room mode605B, enhanced stair mode605C, elevator mode605D, mobile park mode605E, and static storage/charging mode605F. Any of these modes can include a move-to-position mode, or the user can direct transporter120(FIG. 1) to move to a certain position. Message bus54can receive control information in the form of UI data633for transporter120(FIG. 1), and can receive a result of the processing done by UCP assist145in the form of commands such as movement commands630that can include, but are not limited to including, speed and direction. Movement commands630can be provided, by message bus54, to PBPs100(FIG. 4) which can transmit this information to wheel motor drives19/21/31/33(FIGS. 2C/D) and cluster motor drives1050/27(FIGS. 2C/D). Movement commands630can be determined by movement processor603based on information provided by the mode-specific processors. Mode-specific processors can determine mode-dependent data657, among other things, based on information provided through sensor-handling processors661.

Continuing to refer primarily toFIG. 10, sensor-handling processors661can include, but are not limited to including, transporter geometry processor613, PCL processor611, SLAM processor609, and obstacle processor607. Movement processor603can provide movement commands630to the sensor-handling processors661to provide information necessary to determine future movements of transporter120(FIG. 1). Sensors147can provide environmental information651that can include, for example, but not limited to, obstacles623and geometric information about transporter120(FIG. 1). In some configurations, sensors147can include at least one time-of-flight sensor that can be mounted anywhere on transporter120(FIG. 1). There can be multiple of sensors147mounted on transporter120(FIG. 1). PCL processor611can gather and process environmental information651, and can produce PCL data655. The PCL, a group of code libraries for processing 2D/3D image data, can, for example, assist in processing environmental information651. Other processing techniques can be used.

Continuing to refer primarily toFIG. 10, transporter geometry processor613can receive transporter geometry information649from sensors147, can perform any processing necessary to prepare transporter geometry information649for use by the mode-dependent processors, and can provide the processed of transporter geometry information649to the mode-dependent processors. The geometry of transporter120(FIG. 1) can be used for, but is not limited to being used for, automatically determining whether or not transporter120(FIG. 1) can fit in and/or through a space such as, for example, a stairway and a door. SLAM processor609can determine navigation information653based on, for example, but not limited to, UI data633, environmental information651and movement commands630. Transporter120(FIG. 1) can travel in a path at least in part set out by navigation information653. Obstacle processor607can locate obstacles623and distances621to obstacles623. Obstacles623can include, but are not limited to including, doors, stairs, automobiles, and miscellaneous features in the vicinity of the path of transporter120(FIG. 1).

Referring now to FIGS.11A1and11A2, method650for processing at least one obstacle623(FIG. 11B) while navigating transporter120(FIG. 1) can include, but is not limited to including, receiving1151(FIG.11A1) at least one movement command630(FIG. 11B), receiving and segmenting1153(FIG.11A1) PCL data655(FIG. 11B), identifying1155(FIG.11A1) at least one plane within the segmented PCL data655(FIG. 11B), and identifying1157(FIG.11A1) at least one obstacle623(FIG. 11B) within the at least one plane. Method650can further include determining1159(FIG.11A1) at least one situation identifier624(FIG. 11B) based at least on the at least one obstacle, UI data633(FIG. 11B), and movement commands630(FIG. 11B), and determining1161(FIG.11A1) distance621(FIG. 11B) between transporter120(FIG. 1) and at least one obstacle623(FIG. 11B) based at least on at least one situation identifier624(FIG. 11B). Method650can also include accessing1163(FIG.11A1) at least one allowed command related to distance621(FIG. 11B), at least one obstacle623(FIG. 11B), and at least one situation identifier624(FIG. 11B). Method650can still further include accessing1163(FIG.11A1) at least one automatic response to the at least one allowed command, mapping1167(FIG.11A2) at least one movement command630(FIG. 11B) with one of the at least one allowed commands, and providing1169(FIG.11A2) at least one movement command630(FIG. 11B) and the at least one automatic response associated with the mapped allowed command to the mode-dependent processors.

Continuing to refer to FIGS.11A1and11A2, at least one obstacle623(FIG. 11B) can optionally include at least one stationary object and/or at least one moving object. Distance621(FIG. 11B) can optionally include a fixed amount and/or a dynamically-varying amount. At least one movement command630(FIG. 11B) can optionally include a follow command, at least one pass-the-at-least-one-obstacle command, a travel beside-the-at-least-one-obstacle command, and a do-not-follow-the-at-least-one obstacle command. Method650can optionally include storing obstacle data623(FIG. 11B), and allowing access to stored obstacle data, for example, stored in cloud storage607G (FIG. 11B) and/or local storage607H (FIG. 11B), by systems external to transporter120(FIG. 1). PCL data655(FIG. 11B) can optionally include sensor data147(FIG. 10). Method650can optionally include collecting sensor data147(FIG. 10) from at least one time-of-flight sensor mounted on transporter120(FIG. 1), analyzing sensor data147(FIG. 10) using a point cloud library (PCL), tracking the at least one moving object using simultaneous location and mapping (SLAM) with detection and tracking of moving objects (DATMO) based on the location of transporter120(FIG. 1), identifying the at least one plane within obstacle data623(FIG. 11B) using, for example, but not limited to, random sample consensus and a PCL library, and providing the at least one automatic response associated with the mapped allowed command to the mode-dependent processors. Method650can also optionally include receiving a resume command, and providing, following the resume command, at least one movement command630(FIG. 11B) and the at least one automatic response associated with the mapped allowed command to the mode-dependent processors. The at least one automatic response can optionally include a speed control command.

Referring now toFIG. 11B, obstacle processor607for processing at least one obstacle623while navigating transporter120(FIG. 1) can include, but is not limited to including, nav/PCL data processor607F receiving and segmenting PCL data655from PCL processor611, identifying at least one plane within the segmented PCL data655, and identifying at least one obstacle623within the at least one plane. Obstacle processor607can further include distance processor607E determining at least one situation identifier624based at least on UI data633, at least one movement command630, and at least one obstacle623. Distance processor607E can determine distance621between transporter120(FIG. 1) and at least one obstacle623based at least on at least one situation identifier624. Moving object processor607D and/or stationary object processor607C can access at least one allowed command related to distance621, at least one obstacle623, and at least one situation identifier624. Moving object processor607D and/or stationary object processor607C can access at least one automatic response, from automatic response list627, associated with the at least one allowed command. Moving object processor607D and/or stationary object processor607C can access at least one movement command630including, for example, speed/signal command and direction command/signal, and map at least one movement command630with one of the at least one allowed commands. Moving object processor607D and/or stationary object processor607C can provide at least one movement command630and the at least one automatic response associated with the mapped allowed command to the mode-dependent processors.

Continuing to refer toFIG. 11B, stationary object processor607C can optionally perform any special processing necessary when encountering at least one stationary object, and moving object processor607D can optionally perform any special processing necessary when encountering at least one moving object. Distance processor607E can optionally process distance621that can be a fixed and/or a dynamically-varying amount. At least one movement command630can optionally include a follow command, a pass command, a travel-beside command, a move-to-position command, and a do-not-follow command. Nav/PCL processor607F can optionally store obstacles623, for example, but not limited to, in local storage607H and/or on storage cloud607G, and can allow access to the stored obstacles623by systems external to transporter120(FIG. 1) such as, for example, but not limited to, external applications140(FIG. 4). PCL processor611can optionally collect sensor data147(FIG. 10) from at least one time-of-flight camera mounted on transporter120(FIG. 1), and can analyze sensor data147(FIG. 10) using a point cloud library (PCL) to yield PCL data655. Moving object processor607D can optionally track the at least one moving object using navigation information653collected by simultaneous location and mapping (SLAM) processor609based on the location of transporter120(FIG. 1), identify the at least one plane using, for example, but not limited to, random sample consensus and a PCL library, and can provide at least one movement command630based on the at least one automatic response associated with the mapped allowed command to the mode-dependent processors. Obstacle processor607can optionally receive a resume command, and provide, following the resume command, at least one movement command630based on the at least one automatic response associated with the mapped allowed command to the mode-dependent processors. The at least one automatic response can optionally include a speed control command. For example, if joystick133(FIG. 1) indicates a direction that could position transporter120(FIG. 1) in a collision course with obstacle623, such as, for example, a wall, the at least one automatic response can include speed control to protect transporter120(FIG. 1) from a collision. The at least one automatic response could be overridden by a contrary user command, for example, joystick133(FIG. 1) could be released and movement of transporter120(FIG. 1) could be halted. Joystick133(FIG. 1) could then be re-engaged to restart movement of transporter120(FIG. 1) towards obstacle623.

Referring now primarily toFIGS. 12A-12D, environmental information651(FIG. 10) can be received from sensors147(FIG. 10). Any of PBPs100(FIG. 4), UCP130(FIG. 4), and/or UCP assist145(FIG. 10) can process environmental information651(FIG. 10). In some configurations, PCL processor611(FIG. 10) can process environmental information651(FIG. 10) using, for example, and depending upon sensor147(FIG. 10), point cloud library (PCL) functions. As transporter120(FIG. 1) moves along travel path2001(FIG. 12D) around potential obstacles2001A, sensors147(FIG. 10) can detect a cloud of points from, for example, and depending upon sensor147(FIG. 10), box2005(FIGS. 12C-12D) that can include data that could take the shape of frustum2003(FIGS. 12B-12D). A sample consensus method, for example, but not limited to, the random sample consensus method, from, for example, but not limited to, the PCL, can be used to find a plane among the cloud of points. Any of UCP130(FIG. 4), UCP assist145(FIG. 10), and PBPs100(FIG. 4) can create a projected cloud and can determine point cloud inliers, and from these, determine a centroid of the projected cloud. Central reference point148can be used to determine the location of environmental conditions with respect to transporter120. For example, whether transporter120is moving towards or away from an obstacle, or where a door hinge is with respect to transporter120can be determined based on the location of central reference point148. Sensors147(FIG. 10) can include, for example, time-of-flight sensor147A.

Referring now primarily toFIG. 13A, method750for enabling transporter120(FIG. 1) to navigate stairs can include, but is not limited to including, receiving1251at least one stair command, and receiving1253environmental information651(FIG. 10) from sensors147(FIG. 10) mounted on transporter120(FIG. 1) and through obstacle processor607(FIG. 10). Method750can further include locating1255, based on environmental information651(FIG. 10), at least one of staircases643(FIG. 13B) within environmental information651(FIG. 10), and receiving1257selection of selected staircase643A (FIG. 13B) from the at least one of staircases643(FIG. 13B). Method750can still further include measuring1259at least one characteristic645(FIG. 13B) of selected staircase643A (FIG. 13B), and locating1261, based on environmental information651(FIG. 13B), obstacles623(FIG. 13B), if any, on selected staircase643A (FIG. 13B). Method750can also include locating1263, based on environmental information651(FIG. 13B), a last stair of selected staircase643A (FIG. 13B), and providing1265movement commands630(FIG. 13B) to move transporter120(FIG. 1) on selected staircase643A (FIG. 13B) based on the measured at least one characteristic645(FIG. 13B), the last stair, and obstacles623(FIG. 13B), if any. If1267the last stair has not been reached, method750can continue providing movement commands630(FIG. 13B) to move transporter120(FIG. 1). Method750can optionally include locating at least one of staircases643(FIG. 13B) based on GPS data and building and saving a map of selected staircase643A (FIG. 13B) using, for example, but not limited to, SLAM. Method750can also optionally include accessing geometry649(FIG. 13B) of transporter120(FIG. 1), comparing geometry649(FIG. 13B) to at least one of characteristics645(FIG. 13B) of selected staircase643A (FIG. 13B), and modifying the step of navigating based on the step of comparing. At least one of characteristics645(FIG. 13B) can optionally include the height of at least one riser of selected staircase643A (FIG. 13B), the surface texture of the at least one riser, and the surface temperature of the at least one riser. Method750can optionally include generating an alert if the surface temperature falls outside of a threshold range and the surface texture falls outside of a traction set. The threshold range can optionally include temperatures below 33° F. The traction set can optionally include a carpet texture. Method750can further include determining, based on environmental information651(FIG. 13B), the topography of an area surrounding selected staircase643A (FIG. 13B), and generating an alert if the topography is not flat. Method750can still further optionally include accessing a set of extreme circumstances.

Referring now primarily toFIG. 13B, automated navigation of stairs can be enabled by stair processor605C for enabling transporter120(FIG. 1) to navigate stairs. Sensors147(FIG. 10) on transporter120(FIG. 1) can determine if any environmental information651(FIG. 10) includes at least one staircase643. In conjunction with any automatic determination of a location of at least one staircase643, UI data633can include the selection of stair mode215(FIG. 3A) which can invoke an automatic, semi-automatic, or semi-manual stair-climbing process. Either automatic location of at least one staircase643or reception of UI data633can invoke stair processor605C for enhanced stair navigation functions. Stair processor605C can receive data from obstacle processor607such as, for example, at least one obstacle623, distance621to at least one obstacle623, situation624, navigation information653, and geometry information649for transporter120(FIG. 1). Navigation information can include, but is not limited to including, a possible path for transporter120(FIG. 1) to traverse. At least one obstacle623can include, among other obstacles, at least one staircase643. Stair processor605C can locate at least one staircase643, and can either automatically or otherwise determine selected staircase643A based on, for example, but not limited to, navigation information653and/or UI data633and/or transporter geometry information649. Characteristics645of selected staircase643A, such as, for example, riser information, can be used to determine a first stair and distance to next stair640. Stair processor605C can determine movement commands630of transporter120(FIG. 1) based on, for example, but not limited to, characteristics645, distance621, and navigation information647. Movement processor603can move transporter120(FIG. 1) based on movement commands630, and distance to next stair640, and can transfer control to sensor processing661after a stair from selected staircase643A has been traversed. Sensor processing661can either proceed with navigating selected staircase643A or can continue following the path set out by navigation information653, depending upon whether transporter120(FIG. 1) has completed traversing selected staircase643A. While transporter120(FIG. 1) is traversing selected staircase643A, obstacle processor607can detect obstacles623on selected staircase643A and stair processor605C can provide movement commands630to avoid obstacles623. Locations of obstacles623can be stored for future use locally to transporter120(FIG. 1) and/or external to transporter120(FIG. 1).

Continuing to refer primarily toFIG. 13B, stair processor605C can include, but is not limited to including, staircase processor641B receiving at least one stair command included in UI data633, and staircase locator641A receiving environmental information651(FIG. 10) from sensors147(FIG. 10) mounted on transporter120(FIG. 1) through obstacle processor607(FIG. 10). Staircase locator641A can further locate, based on environmental information651(FIG. 10), at least one of staircases643within environmental information651(FIG. 10), and can receive the choice of selected staircase643A from at least one of staircases643. Selected staircase643A can be stored in storage643B for possible future use. Stair characteristics processor641C can measure at least one of characteristics645of selected staircase643A, and can locate, based on environmental information651, at least one obstacle623, if any, on selected staircase643A. Stair movement processor641D can locate, based on environmental information651, a last stair of selected staircase643A, and provide to movement processor603movement commands630for transporter120(FIG. 1) to move on selected staircase643A based on the measured at least one of characteristics645, the last stair, and at least one obstacle623, if any. Staircase locator641A can optionally locate at least one of staircases643based on GPS data, and can build and save a map of selected staircase643A using SLAM. The map can be saved for use locally to transporter120(FIG. 1), and/or for use by other devices. Staircase processor641B can optionally access geometry649of transporter120(FIG. 1), compare geometry649to at least one of characteristics645of selected staircase643A, and can modify the navigation of transporter120(FIG. 1) based on the comparison. Staircase processor641B can optionally generate an alert if the surface temperature of the risers of selected staircase643A falls outside of a threshold range and the surface texture of selected staircase643A falls outside of a traction set. Stair movement processor641D can optionally determine, based on environmental information651(FIG. 10), the topography of an area surrounding selected staircase643A, and can generate an alert if the topography is not flat. Stair movement processor641D can optionally access a set of extreme circumstances.

Referring now primarily to FIGS.14A1-14A2, method850for negotiating door675(FIG. 14B) while maneuvering transporter120(FIG. 1), where door675(FIG. 14B) can include a door swing, a hinge location, and a doorway, can include, but is not limited to including, receiving and segmenting1351(FIG.14A1) environmental information651(FIG. 10) from sensors147(FIG. 10) mounted on transporter120(FIG. 1). Environmental information651(FIG. 10) can include geometry of transporter120(FIG. 1). Method850can include identifying1353(FIG.14A1) at least one plane within the segmented sensor data, and identifying1355(FIG.14A1) door675(FIG. 14B) within the at least one plane. Method850can further include measuring1357(FIG.14A1) door675(FIG. 14B) to provide door measurements. Method850can also include determining1361(FIG.14A1) the door swing. Method850can further include providing1363(FIG.14A2) at least one movement command630(FIG. 14B) to move transporter120(FIG. 1) for access to a handle of door675(FIG. 14B), if necessary, and providing1365(FIG.14A2) at least one movement command630(FIG. 14B) to move transporter120(FIG. 1) away from door675(FIG. 14B), as door675(FIG. 14B) opens, by a distance based on the door measurements. If door675(FIG. 14B) swings in, method850can include providing at least one movement command to move transporter120(FIG. 1) against door675(FIG. 14B), thus positioning door675(FIG. 14B) for movement of transporter120(FIG. 1) through the doorway. Method850can also include providing1367(FIG.14A2) at least one movement command630(FIG. 14B) to move transporter120(FIG. 1) forward through the doorway, transporter120(FIG. 1) maintaining door675(FIG. 14B) in an open position, if the door swing is towards transporter120(FIG. 1).

Referring now toFIG. 14B, sensor processing661can determine, through information from sensors147(FIG. 10), the hinge side of door675, and the direction, angle, and distance of door. Movement processor603can generate commands to PBPs100(FIG. 4) such as start/stop turning left, start/stop turning right, start/stop moving forward, start/stop moving backwards, and can facilitate door mode605A by stopping transporter120(FIG. 1), cancelling the goal that transporter120(FIG. 1) can be aiming to complete, and centering joystick133(FIG. 1). Door processor671B can determine whether door675is, for example, push to open, pull to open, or a slider. Door processor671B can determine the width of door675by determining the current position and orientation of transporter120(FIG. 1), and determining the x/y/z location of the door pivot point. If door processor671B determines that the number of valid points in the image of door675derived from obstacles623and/or PCL data655(FIG. 10) is greater than a threshold, door processor671B can determine the distance from transporter120(FIG. 1) to door675. Door processor671B can determine if door675is moving based on successive samples of PCL data655(FIG. 10) from sensor processor661. In some configurations, door processor671B can assume that a side of transporter120(FIG. 1) is even with the handle side of door675, and can use that assumption, along with the position of the door pivot point, to determine the width of door675.

Continuing to refer primarily toFIG. 14B, if the movement of door675is towards transporter120(FIG. 1), door movement processor671D can generate and provide movement commands630to movement processor603to move transporter120(FIG. 1) backward by a pre-determined or dynamically-determined percentage of the amount door675is moving. Movement processor603can provide movement commands630to UCP130, and UCP130can accept GUI data633A and provide GUI data633A to movement processor603. If door675is moving away from transporter120(FIG. 1), door movement processor671D can generate movement commands630to direct transporter120(FIG. 1) to move forward by a pre-determined or dynamically-determined percentage of the amount that door675moves. The amount transporter120(FIG. 1) moves either forward or backward can be based on the width of door675. Door processor671B can locate the side of door675that provides the open/close function for door675based on the location of the door pivot point. Door processor671B can determine the distance to the plane in front of sensors147(FIG. 4). Door movement processor671D can generate movement commands630to direct transporter120(FIG. 1) to move through door675. Door movement processor671D can wait a pre-selected amount of time for the move of transporter120(FIG. 1) to complete, and door movement processor671D can generate movement commands630to adjust the location of transporter120(FIG. 1) based on the position of door675. Door processor671B can determine the door angle and the door pivot point. Door processor671B can determine if door675is stationary, can determine if door675is moving, and can determine the direction door675is moving. When door mode605A is complete, door movement processor671D can generate movement commands630that can direct transporter120(FIG. 1) to discontinue movement.

Continuing to still further refer primarily toFIG. 14B, door mode605A for negotiating door675while maneuvering transporter120(FIG. 1), where door675can include a door swing, a hinge location, and a doorway, can include, but is not limited to including, sensor processing661receiving and segmenting environmental information651from sensors147(FIG. 10) mounted on transporter120(FIG. 1), where environmental information651can include geometry649of transporter120(FIG. 1). Door mode605A can also include door locator671A identifying at least one plane within the segmented sensor data, and identifying door675within the at least one plane. Door processor671B can include measuring door675to provide door measurements645A. Door movement processor671D can provide at least one movement command630to move transporter120(FIG. 1) away from door675if door measurements645A are smaller than geometry649of transporter (FIG. 1). Door processor671B can also include determining the door swing, and door movement processor671D can provide at least one movement command630to move transporter120(FIG. 1) forward through the doorway. Transporter120(FIG. 1) can open door675and maintain door675in an open position if the door swing is away from transporter120(FIG. 1). Door movement processor671D can provide at least one movement command630to move transporter120(FIG. 1) for access to a handle of door675, and can provide at least one movement command630to move transporter120(FIG. 1) away from door675, as door675opens, by a distance based on door measurements645A. Door movement processor671D can provide at least one movement command630to move transporter120(FIG. 1) forward through the doorway. Transporter120(FIG. 1) can maintain door675in an open position if the door swing is towards transporter120(FIG. 1).

Referring now toFIG. 15A, transporter120(FIG. 1) can automatically negotiate using rest room facilities. UCP assist145(FIG. 4) can automatically locate a door to a rest room, and to a rest room stall, if there are multiple doors, can automatically generate movement commands630(FIG. 15B) to move transporter120(FIG. 1) through the door(s), and can automatically position transporter120(FIG. 1) relative to rest room fixtures. After use of the rest room fixtures is complete, UCP assist145(FIG. 4) can automatically locate the door(s) and automatically generate movement commands630(FIG. 15B) to move transporter120(FIG. 1) through the door(s) to exit the rest room stall and/or rest room. Method950for negotiating, in transporter120(FIG. 1), a rest room stall in a rest room, where the rest room stall can have door675(FIG. 15B), and door675(FIG. 15B) can have a door threshold and a door swing, can include, but is not limited to including, providing1451at least one movement command630(FIG. 15B) to cause transporter120(FIG. 1) to traverse the door threshold entering the rest room. Method950can also include providing1453at least one movement command630(FIG. 15B) to position transporter120(FIG. 1) for accessing an egress handle of the door, and providing1455at least one movement command630(FIG. 15B) to move transporter120(FIG. 1) away from door675(FIG. 15B), as door675(FIG. 15B) closes, if the door swing is towards transporter120(FIG. 1). Method950can also include providing1457at least one movement command630(FIG. 15B) to move transporter120(FIG. 100) toward door675(FIG. 15B), as door675(FIG. 15B) closes, if the door swing is away from transporter120(FIG. 1), and providing1459at least one movement command630(FIG. 15B) to position transporter120(FIG. 1) alongside a first rest room fixture. Method950can include providing1461at least one movement command630(FIG. 15B) to stop transporter120(FIG. 1), and can include providing1463at least one movement command630(FIG. 15B) to position transporter120(FIG. 1) near a second rest room fixture. Method950can include providing1465at least one movement command630(FIG. 15B) to traverse the door threshold to exit the rest room stall.

Continuing to refer primarily toFIG. 15A, automatically traversing the door threshold can optionally include, but is not limited to including, receiving and segmenting1351(FIG.14A1) environmental information651(FIG. 10) from sensors147(FIG. 10) mounted on transporter120(FIG. 1). Environmental information651(FIG. 10) can include geometry of transporter120(FIG. 1). Automatically traversing the door threshold can also optionally include identifying1353(FIG.14A1) at least one plane within the segmented sensor data, and identifying1355(FIG.14A1) door675(FIG. 14B) within the at least one plane. Automatically traversing the door threshold can further optionally include measuring1357(FIG.14A1) door675(FIG. 14B) to provide door measurements, and providing1359(FIG.14A1) at least one movement command630(FIG. 15B) to move transporter120(FIG. 1) away from door675(FIG. 14B) if the door measurements are smaller than geometry649(FIG. 14B) of transporter (FIG. 1). Automatically traversing the door threshold can also optionally include determining1361(FIG.14A1) the door swing, and providing1363(FIG.14A1) at least one movement command630(FIG. 15B) to move transporter120(FIG. 1) forward through the doorway, transporter120(FIG. 1) opening door675(FIG. 14B) and maintaining door675(FIG. 1) in an open position, if the door swing is away from transporter120(FIG. 1). Automatically traversing the door threshold can further optionally include providing1365(FIG.14A2) at least one movement command630(FIG. 15B) to move the transporter for access to a handle of the door, and providing1367(FIG.14A2) at least one movement command630(FIG. 15B) to move transporter120(FIG. 1) away from door675(FIG. 14B), as door675(FIG. 14B) opens, by a distance based on the door measurements. Automatically traversing the door threshold can also optionally include providing1369(FIG.14A2) at least one movement command630(FIG. 15B) to move transporter120(FIG. 1) forward through the doorway, transporter120(FIG. 1) maintaining door675(FIG. 14B) in an open position, if the door swing is towards transporter120(FIG. 1). Method950can optionally include automatically locating the rest room, and automatically driving transporter120(FIG. 1) to the rest room. SLAM techniques can optionally be used to locate a destination, for example, a rest room. UCP assist145can optionally access a database of frequently-visited locations, can receive a selection one of the frequently-visited locations, and can provide at least one movement command630(FIG. 15B) to move transporter120(FIG. 1) to the selected location which can include, for example, but not limited to, a rest room.

Referring now toFIG. 15B, rest room mode605B for negotiating, in transporter120(FIG. 1), a rest room stall in a rest room, where the rest room stall can have a door, and the door can have a door threshold and a door swing, can include, but is not limited to including, door mode605A providing at least one movement command630to cause transporter120(FIG. 1) to traverse the door threshold entering the rest room. The rest room can also include fixtures such as for example, but not limited to, toilets, sinks, and changing tables. Entry/exit processor681C can provide at least one movement command630to position transporter120(FIG. 1) for accessing an egress handle of the door, and can providing at least one movement command630to move the transporter away from the door, as the door closes, if the door swing is towards transporter120(FIG. 1). Entry/exit processor681C can provide at least one movement command630to move transporter120(FIG. 1) toward door675, as door675closes, if the swing of door675is away from transporter120(FIG. 1). Fixture processor681B can provide at least one movement command630to position transporter120(FIG. 1) alongside a first rest room fixture, and can provide at least one movement command to stop transporter120(FIG. 1). Fixture processor681B can also provide at least one movement command630to position transporter120(FIG. 1) near a second rest room fixture. Entry/exit processor681C can provide at least one movement command630to traverse the door threshold to exit the rest room stall.

Referring now to FIGS.16A1and16A2, method1051for automatically storing transporter120in a vehicle, such as, for example, but not limited to, an accessible van, can assist a user in independent use of the vehicle. When the user exits transporter120(FIG. 1) and enters the vehicle, possibly as the vehicle's driver, transporter120(FIG. 1) can remain parked outside of the vehicle. If transporter120(FIG. 1) is to accompany the user in the vehicle for later use, mobile park mode605E (FIG. 16B) can provide movement commands630(FIG. 16B) to transporter120(FIG. 1) to cause transporter120(FIG. 1) to store itself either automatically or upon command, and to be recalled to the door of the vehicle as well. Transporter120(FIG. 1) can be commanded to store itself through commands received from external applications140(FIG. 4), for example. In some configurations, a computer-driven device such as a cell phone, laptop, and/or tablet can be used to execute external application140(FIG. 4) and generate information that could ultimately control transporter120(FIG. 1). In some configurations, transporter120(FIG. 1) can automatically proceed to mobile park mode605E after the user exits transporter120(FIG. 1) when transporter120(FIG. 1) has been placed in park mode by, for example, the user. Movement commands630(FIG. 16B) can include commands to locate the door of the vehicle at which transporter120(FIG. 1) will enter to be stored, and to direct transporter120(FIG. 1) to the door. Mobile park mode605E (FIG. 16B) can determine error conditions such as, for example, but not limited to, if the door is too small for transporter120(FIG. 1) to enter and can alert the user of the error condition through, for example, but not limited to, an audio alert through audio interface150(FIG. 4) and/or a message to external application140(FIG. 4). If the door is wide enough for transporter120(FIG. 1) to enter, mobile park mode605E (FIG. 16B) can provide vehicle control commands to command the vehicle to open the door. Mobile park mode605E (FIG. 16B) can determine when the vehicle door is open and whether or not there is space for transporter120(FIG. 1) to be stored. Mobile park mode605E (FIG. 16B) can invoke obstacle processing607(FIG. 14B) to assist in determining the status of the vehicle door and if there is room in the vehicle to store transporter120(FIG. 1). If mobile park mode605E (FIG. 16B) determines that there is enough room for transporter120(FIG. 1), mobile park mode605E (FIG. 16B) can provide movement commands630(FIG. 16B) to move transporter120(FIG. 1) into the storage space in the vehicle. Mobile park mode605E (FIG. 16B) can provide vehicle control commands to command the vehicle to lock transporter120(FIG. 1) into place, and to close the vehicle door. When transporter120(FIG. 1) is again needed, external application140(FIG. 1), for example, can be used to invoke mobile park mode605E. Mobile park mode605E (FIG. 16B) can recall the status of transporter120(FIG. 1) and can begin processing by providing vehicle control commands to command the vehicle to unlock transporter120(FIG. 1) and open the door of the vehicle. Mobile park mode605E (FIG. 16B) can once again locate the door of the vehicle, or can access the location675A of the door from, for example, local storage607H (FIG. 14B) and/or cloud storage607G (FIG. 14B). Mobile park mode605E (FIG. 16B) can provide movement commands630(FIG. 16B) to move transporter120(FIG. 1) through the vehicle door and to the passenger door to which it had been summoned by, for example, external application140(FIG. 4). In some configurations, the vehicle can be tagged in places such as, for example, the entry door for storage of transporter120(FIG. 1). Mobile park mode605E can recognize the tags, such as, for example, but not limited to, fiducials, bar codes, and/or QR CODES®, and can execute the method described herein as a result of recognizing the tags. Other tags can be included, such as tags within the storage compartment to indicate the proper storage location and tags on vehicle passenger doors. The tags can be RFID enabled, for example, and transporter120(FIG. 1) can include an RFID reader.

Continuing to refer primarily to FIGS.16A1and16A2, method1051for automatically storing transporter120in a vehicle can include, but is not limited to including, providing1551at least one movement command630(FIG. 16B) to locate the door of the vehicle at which transporter120(FIG. 1) will enter to be stored in a storage space in the vehicle, and providing1553at least one movement command630(FIG. 16B) to direct transporter120(FIG. 1) to the door. If1555the vehicle door is wide enough for transporter120(FIG. 1) to enter, method1051can include providing1557at least one vehicle control command to command the vehicle to open the door. If1559the door is open and if1561there is room in the vehicle to store transporter120(FIG. 1), method1051can include providing1563at least one movement command630(FIG. 16B) to move transporter120(FIG. 1) into the storage space in the vehicle. Method1051can include providing1565at least one vehicle control command to command the vehicle to lock transporter120(FIG. 1) into place, and to close the door of the vehicle. If1555the vehicle door is not wide enough, or if1559the vehicle door is not open, or if1561there is no space for transporter120(FIG. 1), method1051can include alerting1567the user, and providing1569at least one movement command630(FIG. 16B) to return transporter120(FIG. 1) to the user.

Continuing to refer primarily to FIGS.16A1and16A2, the at least one movement command630(FIG. 16B) to store transporter120(FIG. 100) can be received from external application140(FIG. 4) and/or automatically generated. Method1051can optionally include alerting the user of error conditions through, for example, but not limited to, an audio alert through audio interface150(FIG. 4) and/or a message to external application140(FIG. 4). Method1051can optionally invoke obstacle processing607(FIG. 14B) to assist in locating the door of the vehicle, to determine if there is enough room in the vehicle to store transporter120(FIG. 1), and to locate any locking mechanism in the vehicle. When transporter120(FIG. 1) is again needed, that is, when the user has arrived at a destination in the vehicle, external application140(FIG. 1), for example, can be used to invoke transporter120(FIG. 1). Method1051can include recalling the status of transporter120(FIG. 1) and can include providing vehicle control commands to command the vehicle to unlock transporter120(FIG. 1) and open the door of the vehicle. Method1051can include locating the door of the vehicle, or can include accessing the location of the vehicle door from, for example, local storage607H (FIG. 14B) and/or cloud storage607G (FIG. 14B). Method1051can include providing movement commands630(FIG. 16B) to move transporter120(FIG. 1) through the vehicle door and to the passenger door to which it had been summoned by, for example, but not limited to, external application140(FIG. 4).

Referring now toFIG. 16B, mobile park mode605E can include, but is not limited to including, vehicle door processor691D that can provide at least one movement command630to locate door675of the vehicle at which transporter120(FIG. 1) will enter to be stored in a storage space in the vehicle. Vehicle door processor691D can also provide at least one movement command630to direct transporter120(FIG. 1) to door675. If door675is wide enough for transporter120(FIG. 1) to enter, vehicle command processor691C can provide at least one vehicle control command to command the vehicle to open door675. If door675is open and if there is room in the vehicle to store transporter120(FIG. 1), space processor691B can provide at least one movement command630to move transporter120(FIG. 1) into the storage space in the vehicle. Vehicle command processor691C can provide at least one vehicle control command to command the vehicle to lock transporter120(FIG. 1) into place, and to close door675of the vehicle. If door675is not wide enough, or if door675is not open, or if there is no space for transporter120(FIG. 1), error processor691E can alert the user, and can provide at least one movement command630to return transporter120(FIG. 1) to the user.

Continuing to refer toFIG. 16B, vehicle door processor691D can optionally recall the status of transporter120(FIG. 1), and vehicle command processor691C can provide vehicle control commands to command the vehicle to unlock transporter120(FIG. 1) and open door675of the vehicle. Vehicle door processor691D can once again locate door675of the vehicle, or can access the location of door675from, for example, local storage607H (FIG. 14B) and/or cloud storage607G (FIG. 14B), and/or door database673B. Vehicle door processor691D can provide movement commands630to move transporter120(FIG. 1) through door675and to the passenger door to which it had been summoned by, for example, external application140(FIG. 4).

Referring now primarily toFIG. 17A, method1150for storing/recharging transporter120(FIG. 1) can assist the user in storing and possibly recharging transporter120(FIG. 1). For example, transporter120(FIG. 1) could be recharged when the user sleeps. After the user exits transporter120(FIG. 1), commands can be initiated at, for example, external application140(FIG. 4), to move perhaps riderless transporter120(FIG. 1) to a storage/docking area. In some configurations, a mode selection by the user while the user occupies transporter120(FIG. 1) can initiate automatic storage/docking functions after the user has exited transporter120(FIG. 1). When transporter120(FIG. 1) is again needed, commands can be initiated by external application140(FIG. 4) to recall transporter120(FIG. 1) to the user. Method1150can include, but is not limited to including, locating1651at least one storage/charging area, and providing1655at least one movement command630(FIG. 17B) to move transporter120(FIG. 1) from a first location to the storage/charging area. Method1150can include locating1657a charging dock in the storage/charging area and providing1663at least one movement command630(FIG. 17B) to couple transporter120(FIG. 1) with the charging dock. Method1150can optionally include providing at least one movement command630(FIG. 17B) to move transporter120(FIG. 1) to the first location when transporter120(FIG. 1) receives an invocation command. If1653there is no storage/charging area, or if1659there is no charging dock, or if1666transporter120(FIG. 1) cannot couple with the charging dock, method1150can optionally include providing1665at least one alert to the user, and providing1667at least one movement command630(FIG. 17B) to move transporter120(FIG. 1) to the first location.

Referring now toFIG. 17B, static storage/charging mode605F can include, but is not limited to including, storage/charging area processor702A that can locate at least one storage/charging area695, and can provide at least one movement command630to move transporter120(FIG. 1) from a first location to storage/charging area695. Coupling processor702D can locate a charging dock in a storage/charging area, and can provide at least one movement command630to couple transporter120(FIG. 1) with the charging dock. Return processor702B can optionally provide at least one movement command630to move transporter120(FIG. 1) to the first location when transporter120(FIG. 1) receives an invocation command. If there is no storage/charging area695, or if there is no charging dock, or if transporter120(FIG. 1) cannot couple with the charging dock, error processor702E can optionally provide at least one alert to the user, and can providing at least one movement command630to move transporter120(FIG. 1) to the first location.

Referring now toFIG. 18A, method1250for negotiating an elevator while maneuvering transporter120(FIG. 1) can assist a user in getting on and off elevator685(FIG. 18B) in transporter120(FIG. 1). Sensor processing661can be used to locate elevator685(FIG. 18B), for example, or elevator location685A (FIG. 18B) can be determined from local storage607H (FIG. 14B) and/or storage cloud607G (FIG. 14B). When elevator685(FIG. 18B) is located, and when the user selects the desired elevator direction, and when elevator685(FIG. 18B) arrives and the door opens, elevator mode605D (FIG. 18B) can provide movement commands630(FIG. 18B) to move transporter120(FIG. 1) into elevator685(FIG. 18B). The geometry of elevator685(FIG. 18B) can be determined and movement commands630(FIG. 18B) can be provided to move transporter120(FIG. 1) into a location that makes it possible for the user to select a desired activity from the elevator selection panel. The location of transporter120(FIG. 1) can also be appropriate for exiting elevator685(FIG. 18B). When the elevator door opens, movement commands630(FIG. 18B) can be provided to move transporter120(FIG. 1) to fully exit elevator685(FIG. 18B). Method1250can include, but is not limited to including, locating1751elevator685(FIG. 18B), where elevator685(FIG. 18B) has an elevator door and an elevator threshold associated with the elevator door. Method1250can include providing1753at least one movement command630(FIG. 18B) to move transporter120(FIG. 1) through the elevator door beyond the elevator threshold. Method1250can also include determining1755the geometry of elevator685(FIG. 18B), and providing1757at least one movement command630(FIG. 18B) to move transporter120(FIG. 1) into a floor selection/exit location relative to the elevator threshold. Method1250can also include providing1759at least one movement command630(FIG. 18B) to move transporter120(FIG. 1) across and beyond the elevator threshold to exit elevator685(FIG. 18B).

Referring now primarily toFIG. 18B, elevator mode605D can include, but is not limited to including, elevator locator711A that can locate elevator685having an elevator door and an elevator threshold associated with the elevator door. Elevator locator711A can save obstacles623, elevators685, and elevator locations685A in elevator database683B, for example. Elevator database683B can be located locally or remotely from transporter120. Entry/exit processor711B can provide at least one movement command630to move transporter120(FIG. 1) through the elevator door beyond the elevator threshold to either enter or exit elevator685. Elevator geometry processor711D can determine the geometry of elevator685. Entry/exit processor711B can provide at least one movement command630to move transporter120(FIG. 1) into a floor selection/exit location relative to the elevator threshold.

Configurations of the present teachings are directed to computer systems for accomplishing the methods discussed in the description herein, and to computer readable media containing programs for accomplishing these methods. The raw data and results can be stored for future retrieval and processing, printed, displayed, transferred to another computer, and/or transferred elsewhere. Communications links can be wired or wireless, for example, using cellular communication systems, military communications systems, and satellite communications systems. Parts of system200A (FIG. 4), for example, can operate on a computer having a variable number of CPUs. Other alternative computer platforms can be used.

The present configuration is also directed to software and/or firmware and/or hardware for accomplishing the methods discussed herein, and computer readable media storing software for accomplishing these methods. The various modules described herein can be accomplished by the same CPU, or can be accomplished by different CPUs tightly or loosely coupled. The various modules can be accomplished by specially-designed integrated circuits. In compliance with the statute, the present configuration has been described in language more or less specific as to structural and methodical features. It is to be understood, however, that the present configuration is not limited to the specific features shown and described, since the means herein disclosed comprise various forms of putting the present teachings into effect.

While the present teachings have been described above in terms of specific configurations, it is to be understood that they are not limited to these disclosed configurations. Many modifications and other configurations will come to mind to those skilled in the art to which this pertains, and which are intended to be and are covered by both this disclosure and the appended claims. It is intended that the scope of the present teachings should be determined by proper interpretation and construction of the appended claims and their legal equivalents, as understood by those of skill in the art relying upon the disclosure in this specification and the attached drawings.