Robotic vehicle insecure pay load detection and response

Various embodiments include methods, devices, and systems of transporting a payload using a robotic vehicle. Various embodiments may include determining whether a payload is securely held by the robotic vehicle, and taking a corrective action in response to determining that the payload is not securely held by the robotic vehicle.

RELATED APPLICATIONS

This application claims the benefit of priority to Indian Provisional Patent Application No. 201741031721, entitled “Robotic Vehicle Insecure Payload Detection and Response” filed Sep. 7, 2017, assigned to the assignee hereof, the entire contents of which are hereby incorporated by reference.

BACKGROUND

Robotic vehicles, such as aerial robotic vehicles, are often used to deliver an item or items (packages, payloads, and/or other cargo). However, occasionally cargo of the robotic vehicle, including the item(s) being delivered or equipment onboard the robotic vehicle, may not be completely attached or come unfastened from the robotic vehicle. As a result, the cargo may shift, further loosen, and/or even separate from the robotic vehicle enroute to a destination. In such cases, the shifting/loosened/separation of cargo may compromise the safety of the cargo, people, property, and/or the robotic vehicle.

SUMMARY

Various embodiments include devices, systems, and methods for transporting a payload using a robotic vehicle. Various embodiments may include determining whether a payload is securely held by the robotic vehicle, and taking a corrective action in response to determining that the payload is not securely held by the robotic vehicle.

In some embodiments, determining whether the payload is securely held by the robotic vehicle may be based on an indication received from a sensor configured to detect changes in where the payload is held by the robotic vehicle. In some embodiments, determining whether the payload is securely held by the robotic vehicle may be based on an indication received from an onboard motor of the robotic vehicle in the form of a change in motor load. In some embodiments, determining whether the payload is securely held by the robotic vehicle may be based on an indication received from an onboard motor of the robotic vehicle in the form of a change in lift profile of the robotic vehicle.

In some embodiments, taking the corrective action may include a processor changing a force applied to the payload by at least one of a payload securing mechanism. In some embodiments, taking the corrective action may include adjusting a navigation plan, which may include changing a route to a destination. In some embodiments, the navigation plan may control at least one navigation characteristic selected from a group including slowing-down, reducing maneuverability, reducing top speed, limiting acceleration, reducing altitude, avoiding dangerous recovery zones, avoiding impractical recovery zones, avoiding a route through or over an occupied area, and avoiding one or more properties. In some embodiments, taking the corrective action may include activating at least one sensor not currently monitoring payload. In some embodiments, taking the corrective action may include transmitting a message indicating the payload is loose. Taking the corrective action may include transmitting via an onboard transmitter a request for assistance. In some embodiments, taking the corrective action may include determining a parking location for the robotic vehicle and controlling the robotic vehicle to park at the determined parking location. In some embodiments, the robotic vehicle may be an aerial robotic vehicle.

Further embodiments include a robotic vehicle having a processor configured to perform operations of any of the methods summarized above. Further embodiments may include a robotic vehicle having means for performing functions of any of the methods summarized above. Further embodiments may include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a robotic vehicle to perform operations of any of the methods summarized above. Further embodiments may include a processing device for use in a robotic vehicle and configured with processor-executable instructions to perform operations of any of the methods summarized above.

DETAILED DESCRIPTION

Various embodiments include robotic vehicles, systems, and/or methods of transporting payload using a robotic vehicle. Various embodiments include methods and robotic vehicles processing devices implementing such methods for automatically determining whether a payload, held by the robotic vehicle carrying one or more payloads, is securely held or has separated from the robotic vehicle. In addition, various embodiments may include taking actions in response to determining that the payload is not securely held by the robotic vehicle or has separated from the robotic vehicle.

As used herein, the terms “robotic vehicle” and “drone” refer to one of various types of vehicles including an onboard computing device configured to provide some autonomous or semi-autonomous capabilities. Examples of robotic vehicles include but are not limited to: aerial robotic vehicles, such as an unmanned aerial vehicle (UAV); ground vehicles (e.g., an autonomous or semi-autonomous car, a vacuum robot, etc.); water-based vehicles (i.e., vehicles configured for operation on the surface of the water or under water); space-based vehicles (e.g., a spacecraft or space probe); and/or some combination thereof. In some embodiments, the robotic vehicle may be manned. In other embodiments, the robotic vehicle may be unmanned. In embodiments in which the robotic vehicle is autonomous, the robotic vehicle may include an onboard computing device configured to maneuver and/or navigate the robotic vehicle without remote operating instructions (i.e., autonomously), such as from a human operator (e.g., via a remote computing device). In embodiments in which the robotic vehicle is semi-autonomous, the robotic vehicle may include an onboard computing device configured to receive some information or instructions, such as from a human operator (e.g., via a remote computing device), and autonomously maneuver and/or navigate the robotic vehicle consistent with the received information or instructions. In some implementations, the robotic vehicle may be an aerial vehicle (unmanned or manned), which may be a rotorcraft or winged aircraft. For example, a rotorcraft (also referred to as a multirotor or multicopter) may include a plurality of propulsion units (e.g., rotors/propellers) that provide propulsion and/or lifting forces for the robotic vehicle. Specific non-limiting examples of rotorcraft include tricopters (three rotors), quadcopters (four rotors), hexacopters (six rotors), and octocopters (eight rotors). However, a rotorcraft may include any number of rotors.

As used herein, the term “payload” refers to any load carried by the robotic vehicle that may be removed from or repositioned on the robotic vehicle. Payload may include things that are carried by the robotic vehicle, including instruments (e.g., cameras, sensors, etc.), components, and packages (e.g., packages for delivery). Payload may include temporary items, such as items, that are carried by the robotic vehicle for a limited duration. In addition, payload may include long-term or permanent items necessary for the operation of the robotic vehicle. Payloads may be directly secured to the robotic vehicle, such as by a payload attachment device, a compartment, and/or area of the robotic vehicle for holding the payload.

As used herein, the expression “securely held” refers to grasping, carrying, or supporting a payload in a fixed location so as not to move, become loose, not to move more than a specified amount, or become separated from the robotic vehicle. Determinations as to whether a payload is securely held may be based on an expected position of the payload (e.g., corresponding to a last known position of the payload), an amount of force applied to a payload, and/or an amount of resistive force imparted by the payload on a payload securing mechanism configured to keep or sustain the payload in a specified position.

As used herein, the expression, “separated from the robotic vehicle” refers to a payload no longer being carried by a robotic vehicle, i.e., the payload is no longer joined to or touching the robotic vehicle.

As used herein, the term “computing device” refers to an electronic device equipped with at least a processor. Examples of computing devices include processors within a security device, a robotic vehicle and/or a mission management computer that are onboard the robotic vehicle, as well as remote computing devices communicating with the robotic vehicle configured to perform operations of the various embodiments. Computing devices may include wireless communication devices (e.g., cellular telephones, wearable devices, smart-phones, web-pads, tablet computers, Internet enabled cellular telephones, Wi-Fi® enabled electronic devices, personal data assistants (PDAs), laptop computers, etc.), personal computers, and servers. In various embodiments, computing devices may be configured with memory and/or storage. Additionally, computing devices referred to in various example embodiments may be coupled to or include wireless communication capabilities implementing various embodiments, such as network transceiver(s) and antenna(s) configured to establish a local area network (LAN) connection (e.g., Wi-Fi® transceivers).

Various embodiments may be implemented within a variety of robotic vehicles, an example of which suitable for use with various embodiments is illustrated inFIGS. 1A and 1B. With reference toFIGS. 1A and 1B, a robotic vehicle, such as an aerial robotic vehicle100, may carry one or more payloads50for transport and delivery to one or more locations. The aerial robotic vehicle100may also include a plurality of rotors120(e.g., four rotors), each driven by a corresponding motor125, used to enable flight for aerial transportation of the one or more payloads50. In addition, a body110of the aerial robotic vehicle100may support the plurality of rotors120, motors125, and a payload securing unit170. The payload securing unit170may include one or more grippers171,172,173,174for holding a separate one of the one or more payloads50. Alternatively, the one or more grippers171,172,173,174may collectively (i.e., together) secure to one of the payloads50. For ease of description and illustration, some details of the aerial robotic vehicle100are omitted such as wiring, frame structure interconnects or other features that would be known to one of skill in the art.

In various embodiments, processing device210may receive an indication of how securely a payload50is held by the aerial robotic vehicle100or an indication that a payload50has separated from the aerial robotic vehicle100. The indication of how securely the payload50is held or whether the payload50has separated may depend on the type of sensor providing the indication or whether the indication is derived from a change in a motor load of the aerial robotic vehicle100.

In various embodiments, the processing device210may determine that one or more of the payloads50is loose or has separated from the aerial robotic vehicle100by detecting a change in motor load on one or more of the motors125or a change in lift profile of the aerial robotic vehicle100, and/or by using one or more onboard sensors. For example, an electronic speed controller in one or more of the motors125may indicate load changes that reflect one or more of the payloads50are loose. A loose payload (e.g.,50) may cause an increase in drag, which may be detected by a change in the lift profile. Thus, a rise in the motor load of more than a designated increase amount, such as 5%, 10%, 15% (or other threshold), may be considered an indication that one or more of the payload50is not securely held by the aerial robotic vehicle100. Also, a reduction in the motor load of a designated decrease amount may be considered an indication that one or more of the payload50has separated. The designated decrease amount may be set based on how much the lightest individual payload element weighs. In response to determining that the payload is not securely held by or has separated from the aerial robotic vehicle100, the processing device210may execute a corrective action.

In various embodiments, the aerial robotic vehicle100may include one or more onboard sensors, such as one or more cameras236, which may provide indications of how securely the one or more payloads50are held. Cameras may be disposed in different types of locations on the aerial robotic vehicle100and one or more of different types of camera may be used. For example, the cameras236may face a payload securing area150or be configured to rotate to face the payload securing area150. The cameras236may be configured to monitor the one or more payloads50and thus used for visually detecting whether any one of the one or more payloads50is moving irregularly, is not positioned appropriately, or is gone completely (i.e., separated from the aerial robotic vehicle100). The cameras236may also be configured to face or rotate to face outwardly for use as navigational aids and/or viewing the surroundings of the aerial robotic vehicle100. A pair of cameras on the aerial robotic vehicle100may be used to perform stereoscopic depth analysis and three-dimensional mapping. One or more markings, such as matrix barcodes, patterns, symbols, shapes, or the like, may be disposed on one or more outer portions of the payloads50, which may be identified within images from the cameras236to detect shifting or separation of the payloads50. In addition, the aerial robotic vehicle100may use the dimensions or shape of the payloads50to recognize and locate the payloads50. A reflective strip (e.g., infrared or ultraviolet reflective) may be included on the payloads50, such as along edges, to facilitate the determination of the position of each of the payloads50. In response to determining that the payload has shifted position or has separated from the aerial robotic vehicle100, the processing device210may execute a corrective action.

In various embodiments, the aerial robotic vehicle100may include one or more other kinds of onboard sensors, such as contact switches, pressure sensors, communication links that when broken may be used like a sensor, strain gauges, weight sensors, an altimeter, and/or the like for detecting whether one or more of the payloads50is out of position (e.g., moving irregularly, not positioned properly, gone completely, etc.). In some embodiments, contact switches and pressure sensors may be used to detect one or more of the payloads50is not directly in contact with one of the grippers171,172,173,174of the payload securing unit170(i.e., an indication part of the payload50is loose or completely separated).

In some embodiments, the communication link(s) may be used to detect one or more of the payloads50is completely separated from the aerial robotic vehicle100(i.e., lost). For example, an a near-field communication (NFC) device (e.g., a radio frequency identifier (RFID) initiator/target pair) attached to both a payload50and the aerial robotic vehicle100, when no longer detected, may indicate a broken short-range communication link, and thus provide an indication that the payload50has separated from the aerial robotic vehicle100.

In some embodiments, the weight sensor may measure a weight of the payload50, which when no longer detected may provide an indication that the payload50has completely separated from the aerial robotic vehicle100(i.e., lost). In some embodiments, the altimeter or the like may be used by the processing device210to detect flight attitude and/or performance changes that may be associated with the one or more payloads50coming loose or separating from the aerial robotic vehicle100. In response to determining that the payload has shifted position or has separated from the aerial robotic vehicle100, the processing device210may execute a corrective action.

FIG. 1Billustrates a loose payload50a(i.e., the payload furthest right in the orientation shown and included in the relief view) as having pivoted or shifted out of place. The payload50amay have pivoted or may be swinging, which may cause the loss of the loose payload50aor may damage the aerial robotic vehicle100, the loose payload50a, or both.

With reference toFIGS. 1A-1B, in various embodiments, the processing device210may take a corrective action, such as (but not limited to) adjusting one or more of the grippers171,172,173,174to re-secure or better secure the loose payload50a. For example, the grippers171,172,173,174may include a gripping and release mechanism, motor, and so on, that may be strong enough to reliably grasp and hold one or more of the payloads50. The gripping and release mechanism may include a motor that drives each of the grippers171,172,173,174and other controls, which may be responsive to grip and release the payloads50. For example, the grippers171,172,173,174may include an articulating claw, configured to grab and hold a portion of each of the payloads50. The processing device210may be coupled to and configured to control whether the articulating claw is open or closed and how much force the articulating claw imparts on items within the claws. In some embodiments, the payloads50may include a protruding coupling element250that is configured to be firmly held by the grippers171,172,173,174. For example, the protruding coupling element250may include a thin rigid rod, protruding from a surface of the payload50, topped with a bulbous element (e.g., a ball) designed to be received and held in the grippers171,172,173,174. One or more of the grippers171,172,173,174may not have been properly closed or may have come loose. To better secure the loose payload, the processing device210may increase the amount of force that a particular gripper (e.g., grippers171,172,173,174) of the payload securing unit170, applies to the protruding coupling element250. The increase in the amount of force applied by the grippers171,172,173,174may cause the loose payload50ato return to the proper arrangement (i.e., to be positioned and/or held properly; e.g., as shown inFIG. 1A).

In various embodiments, in response to determining that the payload50(50a) is not securely held by the aerial robotic vehicle100, the processing device210may increase power to a magnetic coupling in the payload securing unit170to better secure the loose payload50a. The magnetic coupling may be an electromagnetic lock incorporated into the grippers171,172,173,174, which generates a magnetic field configured to attract and hold a complementary surface on each of the payloads50(e.g., the protruding coupling element250or a flat metallic plate). The processing device210may regulate an electric current used to open and/or close the electromagnetic lock. To autonomously better secure the loose payload, the processing device210may increase the intensity of the magnetic field, to increase the attraction to the protruding coupling element250. The increase in the magnetic field may cause the loose payload50ato return to the proper arrangement (i.e., to be positioned and/or held properly; e.g., as shown inFIG. 1A).

In various embodiments, in response to determining that the payload50(50a) is not securely held by the aerial robotic vehicle100, a corrective action that the processing device210may take is to adjust a navigation, such as a flight control parameter of the aerial robotic vehicle100. One or more flight control parameters may affect a flight characteristic of the aerial robotic vehicle100, such as (but not limited to) speed, acceleration, maneuverability, altitude, and/or the like. For example, the processing device210may attempt to prevent the loss or damage of one or more of the payloads50by slowing-down, reducing maneuverability, reducing top speed, limiting acceleration, reducing altitude, avoiding dangerous recovery zones, avoiding impractical recovery zones, avoiding a flight path over people and/or creatures, avoiding a flight path over private or restricted property, and/or the like.

In various embodiments, another corrective action that the processing device210may take is to activate at least one sensor not currently monitoring the one or more payloads50. For example, one of the cameras236that was not on or not facing the payloads50may be activated or turned toward the payloads50. Yet another corrective action the processing device210may take is to transmit a message indicating that one of the payloads50(50a) is loose. The message may even request assistance or further instructions. A further corrective action the processing device210may take is to determining a landing location for the aerial robotic vehicle100to land and directing the aerial robotic vehicle100to land at the determined landing location.

FIGS. 2A and 2Billustrate exemplary weight adjustment device260for the aerial robotic vehicle100according to various embodiments. With reference toFIGS. 1-2B, the loss of one or more of the payloads50may cause an imbalance for the aerial robotic vehicle100that impairs flight mobility, fuel efficiency, and/or makes flight difficult. Thus, the processing device210may use the weight adjustment device260as part of a corrective action in response to determining that one or more of the payloads50has separated from the aerial robotic vehicle100. The weight adjustment device260may include a track that supports various moveable weights261,262,263,264. The processing device210may autonomously adjust a position of one or more of the moveable weights261,262,263,264to balance or move a center of gravity of the aerial robotic vehicle100.

As illustrated inFIGS. 2A and 2B, one of the payloads50is gone (i.e., the payload furthest right and held by gripper174inFIGS. 1A and 1B). The weight adjustment device260may include a motor, gears, chains, and/or pulleys that move one or more of the moveable weights261,262,263,264along a base track. The processing device210may be coupled to the weight adjustment system and configured to control a position of each of the moveable weights261,262,263,264. InFIG. 2A, the loss of one of the payloads50has caused a shift in the center of gravity (i.e., to the left in the configuration shown inFIG. 2A). To autonomously balance the aerial robotic vehicle100, the processing device210may adjust a position of one or more of the moveable weights261,262,263,264. For example, inFIG. 2Bthe processing device210has moved the two right-most moveable weights263,264toward the right.

FIG. 3illustrates another exemplary weight adjustment system270for the aerial robotic vehicle100according to various embodiments. The processing device210may use the weight adjustment system270as part of a corrective action in response to determining that the payload has separated from the aerial robotic vehicle100. With reference toFIGS. 1-3, the weight adjustment system270may include a track, motor, gears, chains, and/or pulleys that moveably support individual ones of the grippers171,172,173,174of the payload securing unit170. The processing device210may autonomously adjust a position of one or more of the grippers171,172,173,174, along with a corresponding payload50carried therein, to balance or move a center of gravity of the aerial robotic vehicle100. InFIG. 3, one of the payloads50is gone (i.e., the payload furthest right and held by gripper174inFIGS. 1A and 1B), leaving an empty gripper174of the payload securing unit170. In response to determining that one of the payloads50is gone (i.e., lost), the processing device210has moved, toward the right, the three right-most grippers172,173,174, and the two payloads50carried therein, which may balance the aerial robotic vehicle100by shifting a center of gravity toward the right.

Various embodiments may be implemented within a variety of robotic vehicles, an example of which that is suitable for use with various embodiments is illustrated inFIG. 4. With reference toFIGS. 1-4, the illustrated robotic vehicle, such as the aerial robotic vehicle100, is a quad copter-style horizontal rotor type aerial robotic vehicle (a.k.a., a “drone”), which may fly in any unobstructed horizontal and vertical direction or may hover in one place. A robotic vehicle may be configured with processing and communication devices that enable the robotic vehicle to navigate, such as by controlling the motors to move, or in the case of an aerial robotic vehicle to achieve flight directionality, and to receive position information and information from other system components including vehicle systems, package delivery service servers and so on. The position information may be associated with the current robotic vehicle position, the robotic vehicle delivery destination, or other locations associated with the robotic vehicle, and the payloads50.

The aerial robotic vehicle100may include the processing device210that is configured to monitor and control the various functionalities, sub-systems, and/or other components of the aerial robotic vehicle100. For example, the processing device210may be configured to monitor and control various functionalities of the aerial robotic vehicle100, such as any combination of modules, software, instructions, circuitry, hardware, etc. related to propulsion, navigation, power management, sensor management, and/or stability management.

The processing device210may house various circuits and devices used to control the operation of the aerial robotic vehicle100. For example, the processing device210may include a processor220that directs the control of the aerial robotic vehicle100. The processor220may include one or more processors configured to execute processor-executable instructions (e.g., applications, routines, scripts, instruction sets, etc.) to control movement (e.g., flight), antenna usage, and other operations of the aerial robotic vehicle100, including operations of various embodiments. In some embodiments, the processing device210may include memory222configured to store data (e.g., navigation or flight plans, obtained sensor data, received messages, etc.) as well as non-volatile storage memory230configured to store pre-programmed data files (e.g., applications, navigation data, etc.). While the various components of the processing device210are illustrated as separate components, some or all of the components (e.g., the processor220, the memory222, and other units) may be integrated together in a single device or module, such as a system-on-chip module (e.g., the SoC215). The processing device210may include one or more hardware interfaces234for coupling to the SoC215or other components.

The processing device210may include more than one SoC215thereby increasing the number of processors220and processor cores. The processing device210may also include processors220that are not associated with the SoC215. Individual processors220may be multi-core processors. The processors220may each be configured for specific purposes that may be the same as or different from other processors220of the processing device210or SoC215. One or more of the processors220and processor cores of the same or different configurations may be grouped together. A group of processors220or processor cores may be referred to as a multi-processor cluster.

The terms “system-on-chip” or “SoC” as used herein refer to a set of interconnected electronic circuits typically, but not exclusively, including one or more processors (e.g.,220), a memory (e.g.,222), and a communication interface (e.g.,224). The SoC215may include a variety of different types of processors220and processor cores, such as a general purpose processor, a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), an accelerated processing unit (APU), a subsystem processor of specific components of the processing device, such as an image processor for a camera subsystem or a display processor for a display, an auxiliary processor, a single-core processor, and a multicore processor. The SoC215may further embody other hardware and hardware combinations, such as a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), other programmable logic device, discrete gate logic, transistor logic, performance monitoring hardware, watchdog hardware, and time references. Integrated circuits may be configured such that the components of the integrated circuit reside on a single piece of semiconductor material, such as silicon.

The SoC215may include one or more processors220. The processing device210may include more than one SoC215, thereby increasing the number of processors220and processor cores. The processing device210may also include processors220that are not associated with the SoC215(i.e., external to the SoC215). Individual processors220may be multi-core processors. The processors220may each be configured for specific purposes that may be the same as or different from other processors220of the processing device210or the SoC215. One or more of the processors220and processor cores of the same or different configurations may be grouped together. A group of processors220or processor cores may be referred to as a multi-processor cluster.

The processing device210may further include one or more sensor(s)236,237,238, which may be used by the processor220to determine flight attitude and location information to control various processes on the aerial robotic vehicle100. For example, in some embodiments, the processor220may use data from sensors236,237,238(e.g., a light sensor using photo-resistors, photodiodes, and/or phototransistors; a contact switch, a strain gauge, pressure sensor, weight sensor, altimeter, etc.) as an input for the aerial robotic vehicle100. As a further example, the one or more sensor(s) may include one or more cameras236, which may be used for a variety of applications. For example, the camera236may be used to facilitate navigation, such as enabling the aerial robotic vehicle100to follow or navigate toward an identified feature such as a road intersection. The camera236may be used for other purposes such as location identification, guiding the aerial robotic vehicle100to land at a drop-off position at a delivery destination, photographing or identifying the recipient of the package or credentials presented by the recipient, and so on. One or more other input units226may also be coupled to the processor220. Various components within the processing device210and/or the SoC215may be coupled together by various circuits, such as a bus225,235or another similar circuitry.

The processing device210may be coupled to each of the plurality of rotors120by way of the corresponding motors125. Optionally, each of the motors125may communicate with a sub-controller130that may handle functions including controlling aspects of the operation of the rotor's associated motor125. Each sub-controller130may include a local processor130aconfigured to execute processor-executable instructions that may be stored in a local memory130b.

In various embodiments, the processing device210may include or be coupled to one or more communication components232, to enable wireless communication with networks and devices through one or more wireless communication links25. Such communication components232may include a wireless transceiver, an onboard antenna, and/or the like for transmitting and receiving wireless signals. The one or more communication components232may be coupled to the communication interface224and may be configured to handle wireless wide area network (WWAN) communication signals (e.g., cellular data networks) and/or wireless local area network (WLAN) communication signals (e.g., Wi-Fi signals, Bluetooth signals, etc.) associated with ground-based transmitters/receivers (e.g., base stations, beacons, Wi-Fi access points, Bluetooth beacons, small cells (picocells, femtocells, etc.), etc.). The one or more communication components232may receive data from radio nodes, such as navigation beacons (e.g., very high frequency (VHF) omni-directional range (VOR) beacons), Wi-Fi access points, cellular network base stations, radio stations, etc.

The processing device210, using the processor220, the one or more communication components232, and an antenna231may be configured to conduct wireless communications with a variety of wireless communication devices, examples of which include the base station20or cell tower, a beacon, server, a smartphone1500, a tablet, or another computing device with which the aerial robotic vehicle100may communicate. The processor220may establish the wireless communication link25with a base station20or mobile device (e.g., a smartphone1500) via the communication components232and the antenna231. In some embodiments, the one or more communication component232may be configured to support multiple connections with different wireless communication devices using different radio access technologies. In some embodiments, the one or more communication component232and the processor220may communicate over a secured communication link. The security communication links may use encryption or another secure means of communication to secure the communication between the one or more communication component232and the processor220.

The base station20may provide the wireless communication link25, which may be a bi-directional link, such as through wireless signals to the aerial robotic vehicle100. The base station20may be coupled via a wired communication link21to a network access center30that provides one or more wired and/or wireless communications connections31,51to a communication network60(e.g., the Internet) and/or remote servers1600. The communication network60may in turn provide access to a remote server1600over a wired network connection41and/or wireless communications connections (not shown).

The remote computing device1500may be configured to control the base station20, the aerial robotic vehicle100, and/or control wireless communications over a wide area network, such as providing a wireless access point and/or other similar network access points using the base station20. In addition, the remote computing device1500and/or the communication network60may provide access to a remote server1600. The aerial robotic vehicle100may be configured to communicate with the remote computing device1500and/or the remote server1600for exchanging various types of communications and data, including location information, navigational commands, data inquiries, and mission data.

The terms “server” or “remote server” are used herein interchangeably to refer to any computing device capable of functioning as a server, such as a master exchange server, web server, and a personal or mobile computing device configured with software to execute server functions (e.g., a “light server”). Thus, various computing devices may function as a server1600, such as any one or all of cellular telephones, smart-phones, web-pads, tablet computers, Internet enabled cellular telephones, wide area network (WAN) enabled electronic devices, laptop computers, personal computers, a computing device specific to the base station20, the remote computing device1500, and similar electronic devices equipped with at least a processor, memory, and configured to communicate with a robotic vehicle. The server1600may be a dedicated computing device or a computing device including a server module (e.g., running an application that may cause the computing device to operate as a server). A server module (or server application) may be a full function server module, or a light or secondary server module (e.g., light or secondary server application). A light server or secondary server may be a slimmed-down version of server type functionality that can be implemented on a personal or mobile computing device, such as a smart phone, thereby enabling it to function as an Internet server (e.g., an enterprise e-mail server) to a limited extent, such as necessary to provide the functionality described herein.

Alternatively, the aerial robotic vehicle100may be configured to communicate directly with the mobile computing device1500using the wireless communication link25, which provides long-range wireless communications to receive instructions. The wireless communication link25may be established between the onboard antenna231of the communication component232and the mobile computing device1500. The communication component232may be configured to receive GPS signals from a satellite or other signals used by the aerial robotic vehicle100.

The mobile computing device1500may be a device located in a remote facility controlled by an operator of the aerial robotic vehicle100or may be a device associated with a recipient of the payload (e.g.,50) being delivered. The mobile computing device1500may alternatively be a server associated with the package delivery service or operator of the aerial robotic vehicle100. The communication component232may support communications with multiple ones of the mobile computing device1500.

The wireless communication link25may allow an operator or remote controller5to communicate (e.g., providing navigational commands, instructions, or exchanging other data) with the aerial robotic vehicle100via the base station20or directly. The wireless communication link25may include a plurality of carrier signals, frequencies, or frequency bands, each of which may include a plurality of logical channels. The wireless communication link25may utilize one or more radio access technologies (RATs). Examples of RATs that may be used in the wireless communication link25include 3GPP Long Term Evolution (LTE), 3G, 4G, 5G, Global System for Mobility (GSM), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile telephony communication technologies cellular RATs. Further examples of RATs that may be used in one or more of the various wireless communication links within the mission environment include medium range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire, and relatively short-range RATs such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE).

Robotic vehicles, such as the aerial robotic vehicle100, may navigate or determine positioning using altimeters or navigation systems, such as Global Navigation Satellite System (GNSS), Global Positioning System (GPS), etc. In some embodiments, the aerial robotic vehicle100may use an alternate source of positioning signals (i.e., other than GNSS, GPS, etc.). The aerial robotic vehicle100may use position information associated with the source of the alternate signals together with additional information (e.g., dead reckoning in combination with last trusted GNSS/GPS location, dead reckoning in combination with a position of the aerial robotic vehicle takeoff zone, etc.) for positioning and navigation in some applications. Thus, the aerial robotic vehicle100may navigate using a combination of navigation techniques, including dead-reckoning, camera-based recognition of the land features below and around the aerial robotic vehicle100(e.g., recognizing a road, landmarks, highway signage, etc.), etc. that may be used instead of or in combination with GNSS/GPS location determination and triangulation or trilateration based on known locations of detected wireless access points.

In some embodiments, the processing device210of the aerial robotic vehicle100may use one or more of various input units226for receiving control instructions, data from human operators or automated/pre-programmed controls, and/or for collecting data indicating various conditions relevant to the aerial robotic vehicle100. For example, the input units226may receive input from one or more of various components, such as camera(s), microphone(s), position information functionalities (e.g., a global positioning system (GPS) receiver for receiving GPS coordinates), flight instruments (e.g., attitude indicator(s), gyroscope(s), anemometer, accelerometer(s), altimeter(s), compass(es), etc.), keypad(s), etc. The camera(s) may be optimized for daytime and/or nighttime operation.

Various embodiments may be implemented within a variety of communication networks, such as private networks between computing devices, public networks between computing devices, or combinations of private and public networks, as well as cellular data networks and satellite communication networks. A robotic vehicle may travel over varying distances over varying terrain including roadways. Therefore, the robotic vehicle may require communications to be maintained while the robotic vehicle is travelling toward a destination in either a docked, moving, landed, and/or flying state.

FIG. 5illustrates a method500of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100), according to various embodiments. With reference toFIG. 1-5, operations of the method500may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method500, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle.

In determination block510, the processor may determine whether the payload of the one or more payloads is securely held by the robotic vehicle based on a received indication of how securely the payload is held by the robotic vehicle. The processor may receive the indication of whether a payload (or each payload from among a plurality of payloads) is securely held by the robotic vehicle from a sensor onboard the robotic vehicle. For example, the received indication may include camera images that show a payload shifting slightly (i.e., not securely held). As a further example, the received indication may include one sensor reading that represents where the payload is held by the robotic vehicle or that represent a shift in position of a payload or represents a payload securing unit (e.g.,170) element that is not closed or improperly closed, which may also mean the payload is not securely held. As a further example, the processor may receive signals from an onboard motor reflecting a change in motor load or a change in lift profile. As a further example, the received indication may show all systems and/or payloads are in their normal state, which may mean the payload is securely held.

In response to determining that the payload is securely held by the robotic vehicle (i.e., determination block510=“Yes”), the processor may proceed with a current navigation plan in block530. The current navigation plan may include a planned route to one or more destinations, as well as various settings, such as navigation parameters for controlling the robotic vehicle en route to the one or more destinations, including maneuvering, power expenditures, etc.

In response to determining that the payload is not securely held by the robotic vehicle (i.e., determination block510=“No”), the processor may make a determination as to whether an attempt should be made to re-secure the loose payload in determination block515.

In determination block515, the processor may take into account various conditions, such as whether one or more previous attempts to re-secure the loose payload where successful or unsuccessful. For example, if corrective actions to re-secure the loose payload have previously been unsuccessfully attempted or unsuccessfully attempted a threshold number of times (e.g., three times), the processor may determine that no further attempts to re-secure the loose payload should be made. As a further example, if the indication of how securely the payload is held, used in determination block510, indicates the payload may imminently separate (i.e., fall off) or is otherwise at risk of compromising the payload and/or the robotic vehicle, the processor may determine that no attempts or further attempts to re-secure the loose payload should be made. As a further example, the indication of how securely the payload is held, used in determination block510, may indicate the robotic vehicle is no longer airworthy and should immediately land, which means that no attempts should be made to re-secure the loose payload.

In response to determining that no attempt should be made to re-secure the loose payload (i.e., determination block515=“No”), the processor may determine a location for the robotic vehicle to park (i.e., a parking location) in block540. In the case of an aerial robotic vehicle (e.g.,100), the parking location may be a landing location. In the case of an emergency (e.g., where the robotic vehicle should stop or land as soon as possible), the parking location may be any suitable location, such as coming to an immediate stop, stopping, near the robotic vehicle's current location, or returning to the location from which the robotic vehicle departed. In the case of an aerial robotic vehicle, the parking location may be immediately below or a brief flight from the aerial robotic vehicle's current location. Once the parking location for the robotic vehicle is determined in block550, the processor may control the robotic vehicle to park at the determined parking location.

In response to determining that an attempt should be made to re-secure the loose payload (i.e., determination block515=“Yes”), the processor may control a payload securing mechanism to change a force applied to hold the payload in block520. Once the processor initiates the change a force, applied to hold the payload, by the payload securing mechanism in block520, or after proceeding with the navigation plan in block530, the processor may determine whether the payload of the one or more payloads is securely held by the robotic vehicle in determination block510.

In some embodiments, the processor may repeat the operations of the method500to detect and respond to one or more payloads that get loose or lost from the robotic vehicle. For example, the processor may repeat the operations of the method500until landing at a destination or after all payloads are removed. As another example, the processor may repeat the operations of the method500at regular intervals while navigating (e.g., during flight), for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

FIG. 6illustrates a method600of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100) according to various embodiments. With reference toFIG. 1-6, operations of the method600may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method600, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle. In the method600, the processor may perform operations of blocks530,540, and550, and determination blocks510and515, of the method500as described.

In response to determining that an attempt should be made to re-secure the loose payload (i.e., determination block515=“Yes”), the processor may change a navigation plan in block620. The change in navigation plan may include adding a maneuver, changing a route, or changing how the robotic vehicle moves or travels. The added maneuver may include an abrupt turn or other sudden movement intended to adjust a position of the payload carried by the robotic vehicle. The change in route may select a new destination or the path to get to a planned destination, such as avoiding dangerous recovery zones, avoiding impractical recovery zones, avoiding a route through or over an occupied area, and avoiding one or more properties. Changing how the robotic vehicle moves or travels may include slowing-down, reducing maneuverability, reducing top speed, limiting acceleration, reducing altitude (i.e., for an aerial robotic vehicle), change speed, acceleration, altitude, or other navigation control parameters.

Once the processor initiates the change in navigation plan in block620, or after proceeding with the navigation plan in block530, the processor may determine whether the payload of the one or more payloads is securely held by the robotic vehicle in determination block510.

In some embodiments, the processor may repeat the operations of the method600to detect and respond to one or more payloads that get loose or lost from the robotic vehicle. For example, the processor may repeat the operations of the method600until landing at a destination or after all payloads are removed. As another example, the processor may repeat the operations of the method600at regular intervals during navigation, for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

FIG. 7illustrates a method700of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100), according to various embodiments. With reference toFIG. 1-7, operations of the method700may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method700, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle. In the method700, the processor may perform operations of blocks530,540, and550, and determination block510, of the method500, and block620of the method600as described.

In response to determining that the payload is not securely held (i.e., determination block510=“No”), the processor may determine whether an additional sensor should be activated in determination block715.

In response to determining that no additional sensor should be activated (i.e., determination block715=“No”), the processor may determine whether the robotic vehicle should proceed with a current navigation plan in determination block725.

In determination block725, the processor may take into account various conditions in order to assess whether the robotic vehicle should maintain a current navigation plan. For example, the received indication used in determination block510, may reflect that the robotic vehicle is unstable, such as due to imbalances or damage, and should immediately park or land in the case of an aerial robotic vehicle. As a further example, if the indication that the payload is not securely held used in determination block510indicates that one or more other payloads may separate (i.e., fall off) at any time or is/are otherwise at risk of compromising the other payloads and/or the robotic vehicle, the processor may determine that the robotic vehicle should not proceed with the current navigation plan.

In response to determining that the payload is securely held by the robotic vehicle (i.e., determination block510=“Yes”) or that the robotic vehicle should proceed with the current navigation plan (i.e., determination block725=“Yes”), the processor may proceed with a current navigation plan in block530.

In response to determining that the robotic vehicle should not proceed with the current navigation plan (i.e., determination block725=“No”), the processor may determine whether the robotic vehicle should stop as soon as possible in determination block730.

In response to determining that the robotic vehicle should not stop as soon as possible (i.e., determination block730=“No”), the processor may change the navigation plan in block620.

In response to determining that the robotic vehicle should stop as soon as possible (i.e., determination block730=“Yes”), the processor may determine a location for the robotic vehicle to park (i.e., a parking location) in block540. In the case of an aerial robotic vehicle (e.g.,100), the parking location may be a landing location. In the case of an emergency, the parking location may mean coming to an immediate stop, stopping near the robotic vehicle's current location, or returning to the location from which the robotic vehicle departed. In the case of an aerial robotic vehicle, the parking location may be immediately below or a brief flight from the aerial robotic vehicle's current location. Once the parking location for the robotic vehicle is determined in block550, the processor may direct the robotic vehicle to park at the determined parking location.

In response to determining that at least one additional sensor should be activated (i.e., determination block715=“Yes”), the processor may activate at least one sensor in block720. The at least one activated sensor in block720may provide more details regarding whether a payload is loose or has separated.

Once the processor activates the at least one sensor not currently monitoring the payload in block720, initiates the change in navigation plan in block620, or after proceeding with the navigation plan in block530, the processor may determine whether the payload of the one or more payloads is securely held by the robotic vehicle in determination block510.

In some embodiments, the processor may repeat the operations of the method700to detect and respond to one or more payloads that get loose or lost from the robotic vehicle. For example, the processor may repeat the operations of the method700until landing at a destination or after all payloads are removed. As another example, the processor may repeat the operations of the method700at regular intervals during navigation, for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

FIG. 8illustrates a method800of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100), according to various embodiments. With reference toFIG. 1-8, operations of the method800may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method800, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle. In the method800, the processor may perform operations of blocks530,540, and550, and determination blocks510and515, of the method500as described.

In response to determining that an attempt should be made to re-secure the loose payload (i.e., determination block515=“Yes”), the processor may transmit a message indicating the payload is loose in block820. The transmitted message may also request instructions on how to further proceed or what corrective action should be taken. Once the processor transmits the message indicating the payload is loose in block820, the processor may determine whether a response message is received in determination block825.

In response to the processor determining that response message is received in determination block825(i.e., determination block825=“Yes”), the processor may follow the response message instructions in block830. The response message instructions may instruct the processor to repeat the operations of method800or one or more of other methods described herein.

In response to the processor determining that no response message is received (i.e., determination block825=“No”), or after proceeding with the navigation plan in block530, the processor may determine whether the payload of the one or more payloads is securely held by the robotic vehicle in determination block510.

In some embodiments, while navigating (e.g., in flight), the processor may repeat the operations of the method800to detect and respond to one or more payloads that get loose or lost from the robotic vehicle. For example, the processor may repeat the operations of the method800until landing at a destination or after all payloads are removed. As another example, the processor may repeat the operations of the method800at regular intervals during navigation, for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

FIG. 9illustrates a method900of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100), according to various embodiments. With reference toFIG. 1-9, operations of the method900may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method900, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle. In the method900, the processor may perform operations of blocks530,540, and550, and determination block510of the method500as described. In this way in the method900, once the processor determines that the payload is not securely held by the robotic vehicle (i.e., determination block510=“No”), the processor proceeds directly to determining a parking location for the robotic vehicle in block540.

In some embodiments, while navigating (e.g., in flight), the processor may repeat the operations of the method900to detect and respond to one or more payloads that get loose or lost from the robotic vehicle. For example, the processor may repeat the operations of the method900until landing at a destination or the determined landing location, or after all payloads are removed. As another example, the processor may repeat the operations of the method900at regular intervals during navigation for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

FIG. 10illustrates a method1000of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100), according to various embodiments. With reference toFIG. 1-10, operations of the method1000may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method1000, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle. In the method1000, the processor may perform operations of blocks530,540, and550of the method500, block620of the method600, and determination block730of the method700, as described.

In determination block1010, the processor may determine whether the payload of the one or more payloads has separated from the robotic vehicle based on a received indication that one or more payloads has separated from the robotic vehicle. The processor may receive signals transmitted from a sensor configured to detect the presence or absence of the one or more payloads. The sensor may be attached to the robotic vehicle (i.e., onboard the robotic vehicle). For example, the received indication may include camera images that show a payload is missing (i.e., payload has separated). As a further example, the processor may receive signals from an onboard motor reflecting a change in motor load (i.e., a significant drop in motor load) or a change in lift profile (i.e., a significant increase in lift). As a further example, the received indication may include one sensor reading that represents a payload has disconnected from a payload securing unit (e.g.,170), which may also mean the payload has separated.

In response to determining that the payload has not separated from the robotic vehicle (i.e., determination block1010=“No”), the processor may proceed with a current navigation plan in block530. The current navigation plan may include a planned route to one or more destinations, as well as various settings, such as navigation parameters for controlling the robotic vehicle enroute to the one or more destinations, including maneuvering, power expenditures, etc.

In response to determining that the payload has separated from the robotic vehicle (i.e., determination block1010=“Yes”), the processor may determine whether the robotic vehicle should proceed with the current navigation plan in determination block1015.

In determination block1015, the processor may take into account various conditions in order to assess whether the robotic vehicle should maintain a current navigation plan. For example, the received indication used in determination block1010, may reflect that the robotic vehicle is unstable, due to imbalances or damage, and should immediately park or land in the case of an aerial robotic vehicle. As a further example, if the indication that the payload has separated, used in determination block1010, indicates that one or more other payloads may imminently separate (i.e., fall off) or is/are otherwise at risk of compromising the other payloads and/or the robotic vehicle, the processor may determine that the robotic vehicle should not proceed with the current navigation plan.

In response to determining that the robotic vehicle may proceed with the current navigation plan (i.e., determination block1015=“Yes”), the processor may proceed with a current navigation plan in block530.

In response to determining that the robotic vehicle should not proceed with the current navigation plan (i.e., determination block1015=“No”), the processor may optionally determine whether another payload onboard the robotic vehicle should be adjusted in optional determination block1020or otherwise determine whether to stop as soon as possible in determination block730. The option to determine whether another payload onboard the robotic vehicle should be adjusted in optional determination block1020may be performed when such an option is available or under other designated circumstances.

In optional determination block1020, the processor may determine whether another payload onboard the robotic vehicle should be adjusted.

In response to determining that another payload onboard the robotic vehicle should be adjusted (i.e., optional determination block1020=“Yes”), the processor may optionally control a payload securing mechanism to adjust a position of the other payload in optional block1025. The other payload being positionally adjusted may be a temporary payload, such as a package for delivery, or may be a weight configured to adjust a center of gravity of the robotic vehicle. The option to adjust a position of the other payload in optional block1025may be performed when such an option is available or under other designated circumstances. Once the adjustment to the position of the other payload is performed in optional block1025, the processor may once again determine whether the robotic vehicle should proceed with the current navigation plan in determination block1015.

In response to determining that another payload onboard the robotic vehicle should not be adjusted (i.e., optional determination block1020=“No”), the processor may determine whether the robotic vehicle should stop as soon as possible in determination block730.

Once the processor changes the navigation plan in block620, or after proceeding with the navigation plan in block530, the processor may determine whether the payload of the one or more payloads has separated from the robotic vehicle in determination block1010.

In some embodiments, the processor may repeat the operations of the method1000to detect and respond to one or more payloads that separated from the robotic vehicle. For example, the processor may repeat the operations of the method1000until stopping or landing at a destination, parking at a determined parking location, or after all payloads are removed. As another example, the processor may repeat the operations of the method1000at regular intervals during navigation, for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

FIG. 11illustrates another method1100of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100), according to various embodiments. With reference toFIG. 1-11, operations of the method1100may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method1100, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle. In the method1100, the processor may perform operations of blocks530,540, and550of the method500; determination blocks725and730of the method700, block830and determination block825of the method800; and determination block1010of the method1000, as described.

In response to determining that the robotic vehicle should proceed with the current navigation plan (i.e., determination block725=“Yes”) or in response to determining the robotic vehicle should stop as soon as possible (i.e., determination block730=“Yes”), the processor may transmit a message indicating the payload has separated in block1120. The transmitted message may also request instructions on how to further proceed or what corrective action should be taken. Once the processor transmits the message indicating the payload has separated in block1120, the processor may determine whether a response message is received in determination block825.

Thus, in the method1100, once the processor determines that no response message is received (i.e., determination block825=“No”), or after proceeding with the navigation plan in block530, the processor may determine whether the payload of the one or more payloads has separated from the robotic vehicle in determination block1010.

In some embodiments, while navigating (e.g., in flight), the processor may repeat the operations of the method1100to detect and respond to one or more payloads that get separated from the robotic vehicle. For example, the processor may repeat the operations of the method1100until landing at a destination or the determined landing location, or after all payloads are removed. As another example, the processor may repeat the operations of the method1100at regular intervals during navigation, for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

FIG. 12illustrates another method1200of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100), according to various embodiments. With reference toFIG. 1-12, operations of the method1200may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method1200, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle. In the method1200, the processor may perform operations of blocks530,540, and550of the method500, determination blocks715and725of the method700, and determination block1010of the method1000, as described.

In response to determining that at least one additional sensor should be activated (i.e., determination block715=“Yes”), the processor may activate at least one sensor for finding the separated payload in block1220. Once the processor activates the at least one sensor in block1220, the processor may control the robotic vehicle, using the sensor activated in block1220, to search for the separated payload in block1230.

In determination block1235, the processor may determine whether the separated payload has been found. In some embodiments, the processor may use a camera in conjunction with image analysis to identify the separated payload. Alternatively, the payload may have a beacon or other transmit a wireless signal that may be received by the robotic vehicle.

In response to determining the separated payload has been found (i.e., determination block1235=“Yes”), the processor may use a transmitter to transmit a message indicating the separated payload has been found in block1240(i.e., “Report found payload that has separated”). The message may provide a location of the found payload. Additionally, the message may include details regarding whether the separated payload may be damaged or destroyed. The message may request assistance in retrieving or protecting the separated payload.

In response to determining the separated payload has not been found (i.e., determination block1235=“No”), the processor may determine whether to continue searching in determination block1237.

In response to determining to continue searching (i.e., determination block1237=“Yes”), the processor may control the robotic vehicle to continue searching for the separated payload in block1230.

In response to determining not to continue searching (i.e., determination block1237=“No”), using the transmitter to transmit a message indicating the separated payload has been found in block1240, or in response to determining that no additional sensor should be activated (i.e., determination block715=“No”), the processor may determine whether the robotic vehicle should proceed with a current navigation plan in determination block725.

In some embodiments, while navigating (e.g., in flight), the processor may repeat the operations of the method1200to detect and respond to one or more payloads that get separated from the robotic vehicle. For example, the processor may repeat the operations of the method1200until landing at a destination or the determined landing location, or after all payloads are removed. As another example, the processor may repeat the operations of the method1200at regular intervals during navigation, for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

FIG. 13illustrates another method1300of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100), according to various embodiments. With reference toFIG. 1-13, operations of the method1300may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method1300, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle. In the method1300, the processor may perform operations of blocks530,540, and550of the method500; determination block725of the method700; and determination block1010of the method1000, as described.

In response to determining that the payload has separated from the robotic vehicle (i.e., determination block1010=“Yes”), the processor may determine whether a weight adjustment is needed onboard the robotic vehicle in determination block1315. A weight adjustment may help balance and/or stabilize the robotic vehicle. The weight adjustment may be performed by activating a payload redistribution device and/or repositioning a weight on the robotic vehicle.

In response to determining that a weight adjustment is not needed (i.e., determination block1315=“No”), the processor may determine whether the robotic vehicle should proceed with a current navigation plan in determination block725.

In response to determining that a weight adjustment is needed (i.e., determination block1315=“Yes”), the processor may adjust a position of a weight on the robotic vehicle in block1320. The adjustment of the position of weight on the robotic vehicle may adjust the center of gravity of the robotic vehicle. For example, the processor may activate a weight adjustment device that changes a position of at least one payload that has not separated from the robotic vehicle. As another example, the processor may activate a weight adjustment device that changes a position of at least one weight, not considered at item for delivery, carried by the robotic vehicle as part of a weight adjustment device.

Once the processor activates a mechanism for adjusting a position of one or more weights on the robotic vehicle in block1320, or after proceeding with the navigation plan in block530, the processor may determine whether the payload of the one or more payloads has separated from the robotic vehicle in determination block1010.

In some embodiments, the processor may repeat the operations of the method1300to detect and respond to one or more payloads that get separated from the robotic vehicle. For example, the processor may repeat the operations of the method1300until landing at a destination or after all payloads are removed. As another example, the processor may repeat the operations of the method1300at regular intervals during navigation, for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

FIG. 14illustrates another method1400of transporting a payload (e.g.,50) using a robotic vehicle (e.g., the aerial robotic vehicle100), according to various embodiments. With reference toFIG. 1-14, operations of the method1400may be performed by a processing device (e.g.,210) of the robotic vehicle or other computing device (e.g., mobile computing device1500or server1600). To perform the operations of the method1400, the robotic vehicle may communicate with the mobile computing device1500and/or the server1600to take a corrective action in response to determining that the payload is not securely held by the robotic vehicle. In the method1400, the processor may perform operations of block530of the method500; determination blocks715and725of the method700; determination block1010of the method1000; and blocks1220,1230, and1240and determination blocks1235and1237of the method1200, as described.

In response to determining that the robotic vehicle should not proceed with the current navigation plan (i.e., determination block725=“No”), the processor may determine whether to park near the separated payload in determination block1415. For example, the location of the separated payload may be known from determination block1235and as reported in block1240.

In response to determining not to park near the separated payload (i.e., determination block1415=“No”), the processor may determine a new navigation plan in block1430. Once a new navigation plan is determined in block1430, the processor may proceed with the new navigation plan in block530.

In response to determining to park near the separated payload (i.e., determination block1415=“Yes”), the processor may determine a parking location for the robotic vehicle near the separated payload in block1420. As used herein, the expression, “near the separated payload” refers to a position in close proximity to or a short distance from a dropped package such that a person or recovery device locating the robotic vehicle will be able to locate the dropped package without having to conduct an extensive search. For example, parking or landing near the separated payload may involve parking or landing within sight of the payload on the ground, which may depend upon the conditions of the surrounding terrain.

In block1430, the processor may control the robotic vehicle to park in the location near the separated payload. In the case of an aerial robotic vehicle (e.g.,100), the parking location may be on top of or hovering over or within line of sight of the separated payload. The robotic vehicle may land/hover over or on the separated payload to protect the separated payload from tampering and/or serve as a locator for finding the separated payload. Once parked near the separated payload, the robotic vehicle may provide video surveillance (i.e., take photographs or video of the separated payload and/or surrounding area). Similarly, the robotic vehicle may hover over the separated payload or land within line-of-sight of the separated payload to help locate the vicinity in which the separated payload may be found.

In optional block1440, the processor may use a transmitter to transmit data regarding the separated payload. For example, the processor may transmit surveillance video showing at least one of the separated payload and at least a portion of the area surround the separated payload. The option to use a transmitter to transmit data regarding the separated payload in optional block1440may be performed when such an option is available or under other designated circumstances.

In some embodiments, the processor may repeat the operations of the method1400to detect and respond to one or more payloads that get separated from the robotic vehicle. For example, the processor may repeat the operations of the method1400until landing at a destination, after all payloads are removed, or after landing or hovering over or within line of sight of the separated payload. As another example, the processor may repeat the operations of the method1400at regular intervals during navigation, for a predefined number of iterations indicated in a navigation plan, or at other times established for doing so.

In some embodiments, communications with the robotic vehicle, such as the aerial robotic vehicle (e.g.,100), may involve interactions with any of a variety of mobile computing devices (e.g., smartphones, tablets, smartwatches, etc.) an example of which is illustrated inFIG. 15. The mobile computing device1500may include a processor1502coupled with the various systems of the mobile computing device1500for communication with and control thereof. For example, the processor1502may be coupled to a touch screen controller1504, radio communication elements, speakers and microphones, and an internal memory1506. The processor1502may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory1506may be volatile or non-volatile memory, and may also be secure and/or encrypted memory, or unsecure and/or unencrypted memory, or any combination thereof. In another embodiment (not shown), the mobile computing device1500may also be coupled to an external memory, such as an external hard drive.

The touch screen controller1504and the processor1502may also be coupled to a touch screen panel1512, such as a resistive-sensing touch screen, capacitive-sensing touch screen, infrared sensing touch screen, etc. Additionally, the display of the mobile computing device1500need not have touch screen capability. The mobile computing device1500may have one or more radio signal transceivers1508(e.g., Peanut, Bluetooth, Bluetooth LE, ZigBee, Wi-Fi®, radio frequency (RF) radio, etc.) and antennae, the mobile computing device antenna1510, for sending and receiving communications, coupled to each other and/or to the processor1502. The radio signal transceivers1508and the mobile computing device antenna1510may be used with the above-mentioned circuitry to implement the various wireless transmission protocol stacks and interfaces. The mobile computing device1500may include a cellular network wireless modem chip1516coupled to the processor that enables communication via a cellular network.

The mobile computing device1500may include a peripheral device connection interface1518coupled to the processor1502. The peripheral device connection interface1518may be singularly configured to accept one type of connection, or may be configured to accept various types of physical and communication connections, common or proprietary, such as USB, FireWire, Thunderbolt, or PCIe. The peripheral device connection interface1518may also be coupled to a similarly configured peripheral device connection port (not shown).

In various embodiments, the mobile computing device1500may include microphones1515. For example, the mobile computing device may have a microphone1515for receiving voice or other audio frequency energy from a user during a call.

The mobile computing device1500may also include speakers1514for providing audio outputs. The mobile computing device1500may also include a housing1520, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components discussed herein. The mobile computing device1500may include a power source1522coupled to the processor1502, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the mobile computing device1500. The mobile computing device1500may also include a physical button1524for receiving user inputs. The mobile computing device1500may also include a power button1526for turning the mobile computing device1500on and off.

In some embodiments, the mobile computing device1500may further include an accelerometer1528, which senses movement, vibration, and other aspects of the device through the ability to detect multi-directional values of and changes in acceleration. In the various embodiments, the accelerometer1528may be used to determine the x, y, and z positions of the mobile computing device1500. Using the information from the accelerometer, a pointing direction of the mobile computing device1500may be detected.

Various forms of computing devices may be used to communicate with a processor of a robotic vehicle, such as the aerial robotic vehicle (e.g.,100), including personal computers, mobile computing devices (e.g., smartphones, etc.), servers, laptop computers, etc., to implement the various embodiments including the embodiments described with reference toFIGS. 1-16. Such computing devices may typically include, at least, the components illustrated inFIG. 16, which illustrates an example server computing device. With reference toFIGS. 1-16, the server1600may typically include a processor1601coupled to volatile memory1602and large capacity nonvolatile memory1603,1604, such as a disk drive. The server1600may also include one or more disc-drives (e.g., compact disc (CD) or digital versatile disc (DVD)) coupled to the processor1601. The server1600may also include network access ports1605(or interfaces) coupled to the processor1601for establishing data connections with a network, such as the Internet and/or a local area network coupled to other system computers and servers. Similarly, the server1600may include additional access ports1606, such as USB, Firewire, Thunderbolt, and the like for coupling to peripherals, external memory, or other devices.