Adjustable Object Avoidance Proximity Threshold Based on Presence of

Propeller Guard(s)

CLAIM OF PRIORITY UNDER 35 U.S.C. § 119

[0001] The present Application for Patent claims priority to Non-Provisional Application No. 15/860,821 entitled“ADJUSTABLE OBJECT AVOIDANCE PROXIMITY THRESHOLD BASED ON PRESENCE OF PROPELLER GUARD(S)” filed January 3, 2018, assigned to the assignee hereof and hereby expressly incorporated by reference herein.

BACKGROUND

[0002] Rotor-based aerial robotic vehicles, also referred to as,“unmanned aerial vehicles,”“UAVs,” or“drones,” are commonly used for a variety of applications, such as surveillance, photography, and/or cargo delivery. Since the propeller blades may present a hazard to nearby creatures and/or objects, the propeller blades may be at least partially covered with propeller guards to provide additional safety. In addition, many drones use obstacle avoidance systems that work in conjunction with vehicle control systems to avoid hitting people, property, and objects. For example, once a drone detects a nearby object, the obstacle avoidance system executing within the drone controller may prevent the drone from approaching the object closer than some minimum distance, which is referred to herein as a“proximity threshold.” The proximity threshold is typically a fixed distance, such as a few feet between the drone and the object.

SUMMARY

[0003] Various embodiments include devices, systems, and methods for operating an aerial robotic vehicle that adjusts how close the robotic vehicle will approach objects based upon whether propeller guards are installed. In various

embodiments, methods implemented by a processor of an aerial robotic vehicle may include determining whether a propeller guard is installed on the aerial robotic vehicle, setting a proximity threshold for collision avoidance based on the determination as to whether the propeller guard is installed on the aerial robotic vehicle, controlling one or more motors of the aerial robotic vehicle using the proximity threshold for collision avoidance. In some embodiments, setting the proximity threshold for collision avoidance may include raising the proximity threshold from a first value to a second value that is higher than the first value in response to determining that the propeller guard is not installed. In some embodiments, setting the proximity threshold for collision avoidance may include lowering the proximity threshold to a first value from a second value that is higher than the first value in response to determining that the propeller guard is installed. In some embodiments, setting the proximity threshold for collision avoidance may include maintaining the proximity threshold at a currently set value.

[0004] Some embodiments may further include determining whether the propeller guard is damaged in response to determining that the propeller guard is installed, in which setting the proximity threshold is further based on the determination of whether the propeller guard is damaged.

[0005] Some embodiments may further include determining whether a propeller guard meets a predetermined standard in response to determining that the propeller guard is installed, in which setting the proximity threshold is further based on the determination of whether the propeller guard meets the

predetermined standard. IN such embodiments, the predetermined standard may include a minimum size for propeller guards and/or a style of the propeller guard.

[0006] Some embodiments may further include obtaining data from a sensor configured to detect whether the propeller guard is installed on the aerial robotic vehicle, analyzing the obtained data to determine whether the propeller guard is installed. In such embodiments, the sensor may be at least one of a contact sensor, a weight sensor, an image sensor, or a radio-frequency identification tag reader. In such embodiments, analyzing the obtained data includes comparing the obtained data to previously collected data indicating the propeller guard is installed, in which the propeller guard is determined to be installed in response to the obtained data matching the previously collected data indicating the propeller guard is installed and the propeller guard is determined to not be installed in response to the obtained data not matching the previously collected data indicating the propeller guard is installed. In such embodiments, analyzing the obtained data may include comparing the obtained data to predetermined parameters indicating the propeller guard is installed, wherein the propeller guard is determined to be installed in response to the obtained data matching the predetermined parameters indicating the propeller guard is installed and the propeller guard is determined to not be installed in response to the obtained data not matching the predetermined parameters indicating the propeller guard is installed.

[0007] Some embodiments may further include obtaining data from the one or more motors indicating a rate of revolution of respective one or more motors, analyzing the obtained data to determine whether the propeller guard is installed. In such embodiments, analyzing the obtained data may include determining how many propeller guards are installed on the aerial robotic vehicle.

[0008] Some embodiments may further include receiving an input override indicating the propeller guard is or is not installed, in which determining whether the propeller guard is installed is further based on the received input override.

[0009] Further embodiments include an aerial robotic vehicle having a sensor for detecting the presence of one or more propeller guards and a processor configured with processor-executable instructions to perform operations of any of the methods summari ed above. Further embodiments include a processing device for use in an aerial robotic vehicle configured to perform operations of any of the methods summari ed above. Further embodiments include a non- transitory processor-readable media having stored thereon processor-executable instructions configured to cause a processor of an aerial robotic vehicle to perform operations of any of the methods described above. Further embodiments include an aerial robotic vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the features of the invention.

[0011] FIG. 1 A is a plan view of an environment in which an aerial robotic vehicle, without propeller guards, is traveling an indirect path around various obstacles, in accordance with various embodiments.

[0012] FIG. 1B is a plan view of the environment of FIG. 1 A, in which an aerial robotic vehicle, with propeller guards mounted thereon, is traveling a more direct path through various obstacles, in accordance with various embodiments.

[0013] FIG. 1C is a plan view of the environment of FIGS. 1 A-1B, in which an aerial robotic vehicle, without propeller guards mounted thereon, performs path planning to travel an indirect path to avoid various obstacles, in accordance with various embodiments.

[0014] FIG. 1D is a plan view of the environment of FIGS. 1A-1C, in which an aerial robotic vehicle, with propeller guards mounted thereon, performs path planning to travel a more direct path through various obstacles, in accordance with various embodiments.

[0015] FIG. 2 is a block diagram illustrating components of an aerial robotic vehicle and a ground station suitable for use in various embodiments.

[0016] FIGS. 3A-3C are diagrams illustrating some conditions in which propeller guards may be installed on an aerial robotic vehicle, in accordance with various embodiments.

[0017] FIG. 4 is a process flow diagram illustrating methods for operating an aerial robotic vehicle, in response to determining whether propeller guards are installed on the aerial robotic vehicle, according to some embodiments. [0018] FIG. 5 is a process flow diagram illustrating methods for operating an aerial robotic vehicle, in response to determining whether detected propeller guards meet a standard, according to some embodiments.

[0019] FIG. 6 is a process flow diagram illustrating methods for operating an aerial robotic vehicle, in response to determining whether propeller guards are installed on the aerial robotic vehicle and whether detected propeller guards meet a standard, according to some embodiments.

[0020] FIG. 7 is a process flow diagram illustrating methods for analyzing obtained data from image sensors, according to some embodiments.

[0021] FIG. 8 is a component block diagram of a remote computing device suitable for use in some embodiments.

DETAILED DESCRIPTION

[0022] Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims.

[0023] Various embodiments include methods and aerial robotic vehicles processing devices implementing such methods for operating the aerial robotic vehicle. In particular, various embodiments determine whether one or more propeller guards are installed on the aerial robotic vehicle from data obtained by one or more sensors. The processing device sets a proximity threshold for collision avoidance based on the determination as to whether the propeller guard is installed on the aerial robotic vehicle. In addition, the processing device controls a motor of the aerial robotic vehicle using the proximity threshold set for collision avoidance.

[0024] The proximity threshold used by conventional obstacle avoidance systems is generally a fixed distance. However, that fixed distance may not be appropriate for all circumstances. For example, when an object detected by onboard sensors is a child that may reach out or an animal that may unexpectedly lunge, a different proximity threshold may be appropriate when propeller guards are installed as compared to when propeller guards are not installed. However, using too large a fixed proximity threshold may inhibit where or how an aerial robotic vehicle operates. For example, in an environment with many objects, a large fixed proximity threshold may mean that the aerial robotic vehicle can only fly within a small area or will not be able to reach other areas because two objects are too close to one another. Also, when propeller guards are installed, there is less of a perception of risk to people nearby the aerial robotic vehicle, in which case a large fixed proximity threshold may overly limit movement of the aerial robotic vehicle. By setting a proximity threshold based on whether propeller guards are installed, various embodiments may increase safety

(including perceived safety by people near the aerial robotic vehicle) and maneuverability (i.e., freedom of movement).

[0025] The term“aerial robotic vehicle” is used herein to refer to various types of vehicles that are capable of autonomous flight and that include at least a processing unit for controlling flight of the vehicle according to stored

instructions (e.g., data indicating a predetermined flight plan, etc.). Aerial robotic vehicles include unmanned aircraft that are capable of flying without any human interaction, with some human interaction (e.g., providing flight instructions to be executed by the processing unit), under partial human control, and under full human control (e.g., during take-off and landings.) Aerial robotic vehicles may be of various design types capable of executing vertical lift-offs, such as helicopter-type drones configured with any number of rotors (e.g., quad- copter aerial robotic vehicles having four rotors, etc.). Although aerial robotic vehicles may be selectively controlled by human operators, aerial robotic vehicles may be capable of independently performing at least a series of instructions, commands, and/or routines for testing flight stability as described herein. An aerial robotic vehicle includes a control system including a processor for executing processor-executable instructions for controlling the various functionalities of the aerial robotic vehicle, such as communications (e.g., wireless signaling via Wi-Fi®, Bluetooth®, Long Term Evolution (LTE), etc.), data collection (e.g., polling sensors, etc.), propulsion/ navigation, power management, and stability management (e.g., calculating center-of-gravity, etc.). Aerial robotic vehicles may or may not be configured to carry payloads during missions, such as surveillance aerial robotic vehicles configured merely to travel to various locations in order to capture camera imagery or delivery aerial robotic vehicles configured to drop-off packages to a destination address and return to an address of origin.

[0026] The term“propeller guard” is used herein to refer to a frame, cage, or other shielding structure that surrounds, or at least partially surrounds, a propeller. The propeller guard generally allows the free rotational movement of the propeller and safeguards the propeller from contact with other objects.

[0027] The term“proximity threshold,” is used herein to refer to a minimum distance between an obstacle and an aerial robotic vehicle that an object avoidance system will allow before controlling the aerial robotic vehicle to move or change a direction of travel away from the obstacle. The proximity threshold is set to a value greater than zero to ensure some offset is maintained between the aerial robotic vehicle and objects nearby.

[0028] 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).

[0029] In some embodiments, setting the proximity threshold for collision avoidance may comprise raising the proximity threshold from a first value to a second value that is higher than the first value in response to determining that the propeller guard is installed. In some embodiments, setting the proximity threshold for collision avoidance may comprise lowering the proximity threshold to the first value from the second value in response to determining that the propeller guard is installed. In some embodiments, setting the proximity threshold for collision avoidance may comprise maintaining the proximity threshold at a currently set value.

[0030] In various embodiments, a processor of an aerial robotic vehicle may be configured to obtain data from one or more sensors configured to detect whether one or more propeller guards is installed on the aerial robotic vehicle. For example, the one or more sensors may include a contact sensor, a weight sensor, an image sensor (e.g., a camera), or a radio-frequency identification reader.

Alternatively, or additionally, the processor may be configured to obtain data from a motor or an electronic speed controller (ESC) driving a motor indicating a rate of revolutions (e.g., revolutions per minute (RPM)), which may be analyzed for determining whether the propeller guard is installed. Since propeller guards will add weight to an aerial robotic vehicle, analyzing propeller RPM data may involve comparing the current RPM to a data table storing an RPM range required to hover with one or more propeller guards installed and/or not installed, and using the comparison to determine how many propeller guards are installed on the aerial robotic vehicle. In addition, the aerial robotic vehicle may be configured to receive an input override, from an operator or control system, indicating the propeller guard is or is not installed. Thus, determining whether the propeller guard is installed is further based on the received input override. [0031] In various embodiments, in response to a processor determining that the propeller guard is installed, the processor may determine whether a detected propeller guard is damaged. In some embodiments, in response to a processor determining that the propeller guard is installed, the processor may determine whether a propeller guard meets a predetermined standard. For example, the predetermined standard may include a particular style and/or a minimum size for propeller guards.

[0032] In some embodiments, the processor may analyze the obtained data from the sensor(s), such as by comparing the obtained data to previously collected data indicating the propeller guard is installed. In this way, the processor may determine that the propeller guard is installed in response to the obtained data matching the previously collected data indicating the propeller guard is installed and the propeller guard is determined to not be installed in response to the obtained data not matching the previously collected data indicating the propeller guard is installed. Additionally, the processor may analyze the obtained data from the sensor by comparing the obtained data to predetermined parameters indicating the propeller guard is installed. Thus, the processor may determine that the propeller guard is installed in response to the obtained data matching the predetermined parameters indicating the propeller guard is installed, and the processor may determine that the propeller guard is not be installed in response to the obtained data not matching the predetermined parameters indicating the propeller guard is installed.

[0033] FIGS. 1A-1D illustrate plan views of an environment 10 in which aerial robotic vehicles may travel, avoiding various obstacles therein. In particular, the environment 10 includes various trees 31, 32, 33, 34 and a human 40 walking a dog 50.

[0034] Operations of an aerial robotic vehicle 100, without propeller guards, within the environment 10, according to various embodiments, are illustrated in FIG. 1 A. With reference to FIG. 1 A, a processor of the aerial robotic vehicle may determine whether a propeller guard is installed on the aerial robotic vehicle based on obtained data. The determination by the processor may be part of a pre flight setup and/or as part of a dynamic inflight analysis. The processor may set a proximity threshold for collision avoidance based on the determination as to whether the propeller guard is installed. Since the aerial robotic vehicle 100 does not have propeller guards installed, the processor may set the proximity threshold to a first distance D 1 that is a higher value than that used when propeller guards are installed. For example, without propeller guards, the first distance Dl associated with a higher proximity threshold may be twenty feet (20’). In contrast, with propeller guards installed, the processor may set the proximity threshold to a second distance that is a lower value, such as ten feet (10’).

[0035] During flight, the processor of the aerial robotic vehicle 100 may apply a currently set proximity threshold to maintain at least the first distance Dl from any obstacles. From position A, when the aerial robotic vehicle 100 approaches objects (e.g., trees 31 - 34, the human 40, or the dog 50), the processor may process data received from onboard sensors (e.g., a camera, radar, lidar, etc.) to detect objects surrounding the aerial robotic vehicle 100 and particularly obstacles to a first path 60. With the proximity threshold set at the first distance Dl, the aerial robotic vehicle 100 is able to maneuver or follow user control commands to fly between the detected objects, such as along the initial part of the first path 60 between trees 32, 33 and 34. The first distance Dl of the proximity threshold establishes a first virtual path boundary 61 that will be clear of objects detected by the onboard sensors. However, once the aerial robotic vehicle 100 reaches position B, near the human 40 and the dog 50, the proximity threshold will prohibit further progress in the direction of those objects. At position B, two of the trees 32, 34 also prevent lateral movement. Thus, the aerial robotic vehicle 100 is forced to backtrack and take a more indirect route around the obstacles.

[0036] Operations of an aerial robotic vehicle 200, which includes propeller guards, within the environment 10, according to various embodiments, are illustrated in FIG. 1B. With reference to FIG. 1A-1B, a processor of the aerial robotic vehicle may determine whether a propeller guard is installed on the aerial robotic vehicle based on obtained data. The determination by the processor may be part of a pre-flight setup and/or as part of a dynamic in-flight analysis. The processor may set a proximity threshold for collision avoidance based on the determination as to whether the propeller guard is installed. Since the aerial robotic vehicle 200 has propeller guards installed, the processor may set the proximity threshold to a second distance D2 (e.g., ten feet) that is a lower value than the distance (i.e., first distance Dl) used when propeller guards are not installed.

[0037] During flight, the processor of the aerial robotic vehicle 200 may apply the currently set proximity threshold to maintain at least the second distance D2 from any obstacles. From position A, with the proximity threshold set at the second distance D2, the aerial robotic vehicle 200 is able to maneuver or follow user control commands to fly between the detected objects, such as along the initial part of the second path 62 between trees 32, 33 and 34. The second distance D2 of the proximity threshold establishes a second virtual path boundary 63 that will be clear of objects detected by the onboard sensors. Once the aerial robotic vehicle 200 reaches position C, near the human 40 and the dog 50, the proximity threshold may allow further progress between the human 40 and the one tree 32 in order to continue a forward progress. Thus, the aerial robotic vehicle 200 is able to travel a more direct path through various obstacles with propeller guards installed and using the lower proximity threshold.

[0038] FIG. 1C illustrates a further embodiment in which one or more proximity thresholds for various objects detected by a processor of an aerial robotic vehicle, in combination with propeller guard detection, may be used in planning a path to avoid approaching any object closer than an appropriate proximity threshold. With reference to FIGS. 1A-1C, the aerial robotic vehicle 100 transiting along an initial path 64 will eventually detect objects in its path, such as the trees 31 - 34, the human 40, and the dog 50. In some embodiments, a processor of the aerial robotic vehicle 100 may evaluate the detected objects, such as through visual processing and image recognition methods and/or additional object location methods, to determine positions, sizes, or other characteristics (e.g., whether the objects are stationary or moving) of each of the objects 31 - 34, 40, 50.

[0039] In addition, the processor of the aerial robotic vehicle 100 may determine whether a propeller guard is installed on the aerial robotic vehicle based on obtained data in order to set one or more proximity thresholds. In some embodiments, the processor may apply different proximity thresholds for different types of objects; a first proximity threshold for static objects and a second proximity threshold for moving (i.e., dynamic) objects. For example, the processor may use one proximity threshold for stationary objects, like the trees 31 - 34, and a different larger proximity threshold for the moving creatures, the human 40 and the dog 50. Since the aerial robotic vehicle 100 does not have propeller guards installed, the processor may set proximity thresholds that are a higher value than those used when propeller guards are installed. In this way, the processor may set a static-object proximity threshold to a first distance Dl l and a dynamic-object proximity threshold to a second distance D12, both first and second distances Dl 1, D12 being a higher value than those used if propeller guards were installed.

[0040] The processor may then determine a boundary surrounding each of the observed objects 31 - 34, 40, 50 corresponding to the particular proximity threshold associated with that object as implemented in the collision avoidance system. Because the various objects have differing appropriate proximity thresholds as described, the processor may take into account all of the determined proximity thresholds in order to plot an avoidance path 65 around all detected objects. In order to do so efficiently, the processor may generate an internal map that includes locations of each of the detected objects and calculates an exclusion perimeter around each object based upon the proximity threshold appropriate for that object. Such an internal map may enable the processor to then determine the avoidance path 65 without having to backtrack and ensure the aerial robotic vehicle 100 does not approach any of the objects closer than their corresponding proximity threshold.

[0041] Operations of an aerial robotic vehicle 200 that includes propeller guards installed thereon and that include a processor that performs path planning, within the environment 10, according to various embodiments, is illustrated in FIG. 1D. With reference to FIGS. 1A-1D, a processor of the aerial robotic vehicle 200 may evaluate the detected objects and apply appropriate proximity thresholds to each. For example, since the aerial robotic vehicle 100 has propeller guards installed, the processor may set proximity thresholds that are a lower value than those used when propeller guards are not installed. In this way, the processor may set a static-object proximity threshold to a third distance D21 and a dynamic-object proximity threshold to a fourth distance D22, both third and fourth distances D21, D22 being a lower value than those used if propeller guards were not installed.

[0042] The processor may determine a boundary surrounding each of the observed objects 31 - 34, 40, 50 corresponding to the particular proximity threshold associated with that object as implemented in the collision avoidance system. Because the various objects have differing appropriate proximity thresholds as described, the processor may take into account all of the determined proximity thresholds in order to plot an avoidance path 66 between some of the detected objects. The processor may generate an internal map that enables the processor to then determine the avoidance path 66 and ensure the aerial robotic vehicle 200 does not approach any of the objects closer than their corresponding proximity threshold.

[0043] Various embodiments may be implemented within a variety of aerial robotic vehicles configured to communicate with one or more communication networks, an example of which in the form of an aerial robotic vehicle 200 suitable for use with various embodiments is illustrated in FIG. 2. With reference to FIGS. 1 A-2, the aerial robotic vehicle 200, operating in a mission environment 20, may include a plurality of rotors 120 (e.g., four rotors), each driven by a corresponding motor 125. A body 110 of the aerial robotic vehicle 200 may support the plurality of rotors 120 and motors 125, as well as propeller guards 250.

[0044] The aerial robotic vehicle 200 may include one or more onboard sensors, such as one or more cameras 236, or other sensors like contact sensors, weight sensors, or a radio-frequency identification reader. The aerial robotic vehicle 200 may include a processing device 210, which may further include one or more attitude sensors, such as an altimeter, a gyroscope, accelerometers, an electronic compass, a satellite positioning system receiver, etc., that may be used by the processor 220 to determine vehicle attitude and location information for controlling flight and navigation.

[0045] Cameras 236 may be disposed in various locations on the aerial robotic vehicle 200 and different types of camera may be used. For example, a first set of cameras 236 may face a side of each of the rotors 120 in the plane of rotation thereof, such as mounted near a central part of the aerial robotic vehicle 200. Additionally or alternatively, second set of cameras 236 may be mounted under the rotors 120, such as in a position configured to detect whether propeller guards 250 are installed.

[0046] Image data generated by the cameras 236 may be used by an object avoidance system executing in the processor 220. In various embodiments, image data received from cameras 236 may be processed by an object avoidance system to detect whether propeller guards are installed. The image data received from cameras 236 may also be processed by an object avoidance system to inspect for damage to propeller guards 250. In some embodiments, active sensors (not shown) located away from the rotors, but still on the aerial robotic vehicle, may enable the processor to detect the presence of propeller guards by measuring certain materials embedded in or on propeller guards.

[0047] The aerial robotic vehicle 200 may include a processing device 210 that may be coupled to each of the plurality of motors 125 that drive the rotors 120. The processing device 210 may be configured to monitor and control the various functionalities, sub-systems, and components of the aerial robotic vehicle 200. For example, the processing device 210 may be configured to monitor and control various modules, software, instructions, circuitry, hardware, etc. related to propulsion, navigation, power management, sensor management, and/or stability management.

[0048] The processing device 210 may house various circuits and devices used to control the operation of the aerial robotic vehicle 200. For example, the processing device 210 may include a processor 220 that directs the control of the aerial robotic vehicle 200. The processor 220 may include one or more processors configured to execute processor-executable instructions (e.g., applications, routines, scripts, instruction sets, etc.) to control flight, antenna usage, and other operations of the aerial robotic vehicle 200, including operations of various embodiments. In some embodiments, the processing device 210 may include memory 222 coupled to the processor 220 and configured to store data (e.g., flight plans, obtained sensor data, received messages/inputs, applications, etc.). The processor 220 and memory 222 may be configured as or be included within a system-on-chip (SoC) 215 along with additional elements such as (but not limited to) a communication interface 224, one or more input units 226, non volatile storage memory 230, and a hardware interface 234 configured for interfacing the SoC 215 with hardware and components of the aerial robotic vehicle 200. Components within the processing device 210 and/or the SoC 215 may be coupled together by various circuits, such as a bus 225, 235 or another similar circuitry.

[0049] The processing device 210 may include more than one SoC 215 thereby increasing the number of processors 220 and processor cores. The processing device 210 may also include processors 220 that are not associated with the SoC 215. Individual processors 220 may be multi-core processors. The processors 220 may each be configured for specific purposes that may be the same as or different from other processors 220 of the processing device 210 or SoC 215. One or more of the processors 220 and processor cores of the same or different configurations may be grouped together. A group of processors 220 or processor cores may be referred to as a multi-processor cluster.

[0050] The terms“system-on-chip” or“SoC” are used herein to 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 SoC 215 may include a variety of different types of processors 220 and 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 SoC 215 may 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.

[0051] In various embodiments, the processing device 210 may include or be coupled to one or more communication components 232, such as a wireless transceiver, an onboard antenna, and/or the like for transmitting and receiving wireless signals through the wireless communication link 25. The one or more communication components 232 may be coupled to the communication interface 224 and 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 components 232 may 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.

[0052] The processing device 210, using the processor 220, the one or more communication components 232, and an antenna may be configured to conduct wireless communications with a variety of remote computing devices, examples of which include the base station or cell tower (e.g., base station 20), a beacon, server, a smartphone, a tablet, or another computing device with which the aerial robotic vehicle 200 may communicate. The processor 220 may establish the wireless communication link 25 via a modem and the antenna. In some embodiments, the one or more communication components 232 may be configured to support multiple connections with different remote computing devices using different radio access technologies. In some embodiments, the one or more communication components 232 and the processor 220 may

communicate over a secured communication link. The security communication links may use encryption or another secure means of communication in order to secure the communication between the one or more communication components 232 and the processor 220.

[0053] The aerial robotic vehicle 200 may operate in the mission environment 20 communicating with a base station 70, which may provide a communication link to a remote computing device 75 and/or a remote server 80 via a communication network 90. The base station 70 may provide the wireless communication link 25, such as through wireless signals to the aerial robotic vehicle 200. The remote computing device 75 may be configured to control the base station 70, the aerial robotic vehicle 200, and/or control wireless communications over a wide area network, such as providing a wireless access points and/or other similar network access point using the base station 70. In addition, the remote computing device 75 and/or the communication network 90 may provide access to a remote server 80. The aerial robotic vehicle 200 may be configured to communicate with the remote computing device 75 and/or the remote server 80 for exchanging various types of communications and data, including location information, navigational commands, data inquiries, and mission data.

[0054] Aerial robotic vehicles 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 vehicle 200 may use an alternate source of positioning signals (i.e., other than GNSS, GPS, etc.). The aerial robotic vehicle 200 may 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 vehicle 200 may navigate using a combination of navigation techniques, including dead-reckoning, camera-based recognition of the land features below and around the aerial robotic vehicle 200 (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.

[0055] In some embodiments, the processing device 210 of the aerial robotic vehicle 200 may use one or more of various input units 226 for 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 vehicle 200. For example, the input units 226 may 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. [0056] Aerial robotic vehicles may be winged or rotor craft varieties. For example, the aerial robotic vehicle 200 may be a rotary propulsion design that utilizes one or more rotors 120 driven by corresponding motors to provide lift-off (or take-off) as well as other aerial movements (e.g., forward progression, ascension, descending, lateral movements, tilting, rotating, etc.). The aerial robotic vehicle 200 is illustrated as an example of an aerial robotic vehicle that may utilize various embodiments, but is not intended to imply or require that various embodiments are limited to a quad-rotor aircraft.

[0057] FIGS. 3A-3C illustrate exemplary conditions in which propeller guards 350 may be installed on an aerial robotic vehicle that may be detected with systems and methods according to various embodiments. With reference to FIGS. 1-3C, the propeller guards 350 are merely illustrative and should not be considered to limit the possible propeller guards that may be detected by an aerial robotic vehicle (e.g., 200).

[0058] The processor (e.g., 220) of an aerial robotic vehicle (e.g., 200) may perform monitoring operations (e.g., data collection and processing) before, during, and/or after flight, such as by accessing readings from on-board sensors to determine whether propeller guards are installed, damaged, and/or meet certain standards. In particular, the processor may receive and analyze images (i.e., video or still images) from one or more cameras (e.g., cameras 236). The images received by the processor may show all or part of any propeller guards present during inspection. Camera angles that provide images of the area surrounding each rotor 120 may be preferred for determining whether propeller guards are installed.

[0059] FIG. 3A illustrates the aerial robotic vehicle 200 with a propeller guard 350 that completely surrounds each of the four rotors 120. The processor of the aerial robotic vehicle analyzing an image of the area around each the rotors 120 (obtained by the cameras 236) may recognize that a fixed structure surrounds all or part of each rotor 120 or that the fixed structure surrounding the rotor 120 matches a shape of a propeller guard. [0060] FIG. 3B illustrates the aerial robotic vehicle 200 with three out of four propeller guards 350 (i.e., one propeller guard is not present). The missing propeller guard may have fallen off or was never installed. The processor of the aerial robotic vehicle analyzing an image of the area around each the rotors 120 (obtained by the cameras 236) may recognize that no propeller guard is installed around one rotor 120.

[0061] FIG. 3C illustrates the aerial robotic vehicle 200 with a propeller guard 350 surrounding three out of four rotors 120 and a fourth damaged propeller guard 351 partially surrounding one of the rotors 120. In addition to recognizing that propeller guards 350, 351 are installed, the processor may analyze a shape of the propeller guards 350, 351 to determine whether any of the propeller guards 350, 351 are damaged. In various embodiments, a significantly damaged propeller guard may be treated the same was as a missing propeller guard. Thus, the processor may set the proximity threshold to a lower value in response to determining that the propeller guard is not damaged, but set the proximity threshold to a higher value in response to determining that the propeller guard is damaged.

[0062] In some embodiments, the processor may determine whether an installed propeller guard is damaged through visual processing and image recognition methods. For example, images received by the processor of an installed propeller guard may be compared to previously stored images of undamaged propeller guards. In addition, the detected structure of a propeller guard may be examined for a crack, gap, rip, nick, bend, crease, fracture, and or other physical

deficiencies in continuity. Further, sensors may be used to detect unusual vibrations, movement, or other deviations from normal conditions that may indicate something is wrong with an installed propeller guard. The processor may use stringent requirements for considering a propeller guard undamaged, such as any minor deviation from a standard propeller guard shape being considered damaged. In the event that a non-standard profile shape of a currently installed propeller guard is detected, the propeller guard may be considered, "damaged," and error message may be output by the processor to make an operator or owner of the aerial robotic vehicle aware of the condition.

[0063] Additionally or alternatively, if some discontinuity or irregularity is detected, the processor may assess, based on the degree of a normal profile shape that is missing, whether the propeller guards 350, 351 should be considered to be damaged. While a propeller guard may have minor irregularities, the overall structure may serve the intended purpose of guarding the rotor 120 from impact with obstacles (i.e., objects). For example, if less than 2% of the overall structure of a propeller guard (e.g., 351) is missing, the processor may determine the propeller guard 351 is not damaged. In addition, the determination regarding propeller guard damage may depend on where the damage is located. For example, if only an inner portion of the propeller guard 351 (i.e., facing the center of the aerial robotic vehicle) had been missing, the discontinuity may not be considered significant enough to treat the propeller guard in the same way that a missing propeller guard is treated (i.e., maintain the higher proximity

threshold). In the event that minor defects are detected, but the propeller guard is not considered "damaged," an error message may be output by the processor to make an operator or owner of the aerial robotic vehicle aware of the condition.

[0064] In some embodiments, the processor may also determine whether an installed propeller guard meets a predetermined standard for propeller guards. Similar to the damage assessment described above, the processor may determine whether an installed propeller guard meets the predetermined standard through visual processing and image recognition methods. The predetermined standard may include a minimum size or style of propeller guards.

[0065] FIG. 4 illustrates a method 400 for operating an aerial robotic vehicle according to some embodiments. With reference to FIGS. 1 A-4, the method 400 may be performed by a processor, such as a processor (220) within a processing device (e.g., 210) of an aerial robotic vehicle (e.g., 100, 200) to detect whether propeller guards (e.g., 250, 350) are installed and set a proximity threshold accordingly in response thereto. [0066] In block 405, the processor may initiate a test for setting the proximity threshold. The test for setting the proximity threshold may be initiated at start-up (i.e., when the processor is turned on or woken up from a sleep mode).

Additionally, the test for setting the proximity threshold may be initiated when conditions change. For example, upon receipt by the processor of an input from a sensor, like a contact sensor, the test for setting the proximity threshold may be automatically initiated. As a further example, in response to an event, such as a crash or heavy impact to the aerial robotic vehicle, the processor may force the initiation of the test for setting the proximity threshold. In addition, the aerial robotic vehicle may be configured to receive an input override, from an operator or control system, indicating the propeller guard is or is not installed. The input override may supersede any determination regarding whether the propeller guard is installed based on sensor data.

[0067] In some embodiments, the processor may repeat the operations of the method 400 to detect and respond to rotor anomalies in all rotors of an aerial robotic vehicle having one or more rotors. For example, the processor may repeat the operations of the method 400 continuously or until all rotors are checked to ensure safe and proper operation of the aerial robotic vehicle. As another example, the processor may repeat the operations of the method 400 for a predefined number of iterations indicated in pre-flight testing instructions provided to the aerial robotic vehicle before take-off. Thereafter, the processor may optionally repeat the operations of the method 400 at regular intervals during flight or at other times established for doing so.

[0068] In block 410, the processor may obtain sensor data from one or more sensors that are configured to detect whether a propeller guard is installed on the aerial robotic vehicle. Additionally or alternatively as part of the operations in block 410, the processor may obtain propeller rotation speed data from one or more ESCs and/or one or more motors of the aerial robotic vehicle that can be analyzed to determine whether one or more a propeller guard is installed on the aerial robotic vehicle. Such obtained data may be stored in local memory, such as a buffer, to support image processing in subsequent operations. The obtained data may be stored for tracking usage history or incident data (e.g., an unusual circumstance detected). In addition, stored data may be used for subsequent comparison with image analysis for recognizing the same propeller guards, if removed and later reinstalled on the aerial robotic vehicle.

[0069] Cameras (e.g., 236) may be used exclusively or in combination with other sensors. One or more cameras may be mounted under the rotors or in the plane of the rotors. Structural anomalies (e.g., rips, nicks, bends, creases, or similar damage) may be detected through analysis of still images. Camera images may be used to detect a missing propeller guard (e.g., fallen off or was ripped off). The processor may receive images from one or more cameras (e.g., 236) that image the propellers, and thus will image propeller guards, if in place. In some implementations, the processor may receive image data from multiple cameras, which may enable the processor to better assess structures installed near the rotors to determine whether such structures are propeller guards and if such structures are propeller guards whether the propeller guards are damaged and/or properly installed.

[0070] The processor may additionally or alternatively receive data from other types of sensors, such as contact sensors and/or weight sensors that are activated when propeller guards are installed, if in place. Conductive material may be embedded in or on the propeller guards, which when in contact with a receiving conductive material of the aerial robotic vehicle may indicate a propeller guard is installed. Similarly, a portion of the rotor motors (e.g., where propeller guards may be installed) may include strain gauges that are configured to detect when propeller guards are installed. Also, resistive or capacitive sensors may be attached to or embedded in propeller guards. Additionally, or alternatively, active sensors mounted on a body of the aerial robotic vehicle, but remote from the rotors, may measure passive material embedded in or on one or more propeller guards. For example, the processor may receive data from a radio frequency identification (RFID) reader configured to detect the presence of an RFID transmitter that may be included on or embedded in propeller guards for detection by the processor.

[0071] In embodiments in which the processor additionally or alternatively receives data from one or more motors of the aerial robotic vehicle indicating a rate of revolution (e.g., rpm) of the respective one or more rotors, the processor may use the rate of revolution of the one or more motors to determine whether or not a propeller guard is installed. The rate of revolution of a motor may be directly related to the thrust produced by a propeller associated with that motor. When one or more propeller guards are installed on the aerial robotic vehicle, the aerial robotic vehicle will weigh a little bit more in flight. Such extra weight may require the motors to spin faster in order to maintain level flight or perform flight maneuvers. This extra weight may be deduced from the rate of revolution of the motors, may be associated with something extra being installed on the aerial robotic vehicle, such as one or more propeller guards.

[0072] In block 420, the processor (or another processor configured to perform such analysis) may analyze the obtained data to determine whether a propeller guard is installed on the aerial robotic vehicle. For example, using camera image data, the processor may perform analysis image processing analysis to detect edges, masses and other features characteristic of propeller guards within the field of view. As another example, the processor may recognize contact and/or weight sensor signals, as well as signals from an RFID reader if included, that indicate a propeller guard is installed.

[0073] Alternatively, or additionally, the processor may analyze the rate of revolution of one or more motors to determine how many propeller guards are installed or whether all propeller guards are installed. For example, if only three propeller guards are installed on the aerial robotic vehicle, then the weight of the aerial robotic vehicle will be less (and thus the rotor rotation rate will be less) than when four propeller guards are installed. Additionally, the center of gravity of the aerial robotic vehicle may change if not all propeller guards are installed, which may be detected by comparing the rate of revolution of the various rotors. The rate of revolution of the one or more rotors may be slightly higher when the geometric center of the aerial robotic vehicle does not coincide with the vehicle’s center of gravity. Additionally, during motion of the aerial robotic vehicle, the processor may consider angular velocity data in conjunction with the rotor rate of revolution data to compute a moment of inertia of the aerial robotic vehicle. If the computed moment of inertia is different from a base-line or default, this may be an indication that additional mass consistent with rotor guards is installed or has been removed.

[0074] In some embodiments, the analysis regarding whether a propeller guard is installed may be based solely on detection of the presence of one or more propeller guards (e.g., receiving an indication a propeller guard is installed from a contact sensor). In some embodiments, the determination regarding whether a propeller guard is installed may involve further analysis regarding characteristics of structures installed near the rotors to determine whether such structures are propeller guards, whether detected propeller guards are undamaged, and/or whether detected propeller guards meet predetermined standards.

[0075] In determination block 425, the processor may determine whether a propeller guard is installed based on the data analyzed in block 420.

[0076] In response to determining that a propeller guard is not installed (i.e., determination block 425 =“No”), the processor may set the proximity threshold to a higher value in block 440. The higher value proximity threshold may be a distance considered to be safe or non-threaten to surrounding objects when propeller guards are not installed on the aerial robotic vehicle. In contrast, a lower value proximity threshold may be a distance considered to be safe or non- threaten to surrounding objects when propeller guards are installed on the aerial robotic vehicle.

[0077] In response to determining that a propeller guard is installed (i.e., determination block 425 =“Yes”), the processor may determine whether a propeller guard (i.e., the propeller guard determined to be installed in determination block 425) is damaged in determination block 430. Optionally or alternatively, in response to determining that a propeller guard is installed (i.e., determination block 425 =“Yes”), the processor may set the proximity threshold to the lower value in block 445.

[0078] In response to determining that the propeller guard is damaged (i.e., determination block 430 =“Yes”), the processor may set the proximity threshold to the higher value in block 440. Alternatively, or additionally, the processor may issue a maintenance alert or force maintenance in response to determining that the propeller guard is damaged (i.e., determination block 430 =“Yes”).

[0079] In response to determining that propeller guard is not damaged (i.e., determination block 430 =“No”), the processor may set the proximity threshold to the lower value in block 445.

[0080] Setting the proximity threshold in blocks 440 and/or 445 may or may not involve changing the current proximity threshold value, depending on the current proximity threshold setting and the desired proximity threshold setting based on the determination as to whether the propeller guard is installed on the aerial robotic vehicle. For example, setting the proximity threshold for collision avoidance may include raising the proximity threshold from a first value to a second value that is higher than the first value in response to determining that the propeller guard is not installed. As a further example, setting the proximity threshold for collision avoidance may include lowering the proximity threshold to the first value from the second value in response to determining that the propeller guard is installed. Setting the proximity threshold for collision avoidance may also include maintaining the proximity threshold at a currently set value. For example, setting the proximity threshold for collision avoidance may include leaving the proximity threshold at the first value, which is lower than the second value, in response to determining that the propeller guard is installed and the currently set value of the proximity threshold already being the first value.

As a further example, setting the proximity threshold for collision avoidance may include leaving the proximity threshold at the second value, which is higher than the first value, in response to determining that the propeller guard is not installed and the currently set value of the proximity threshold already being the second value.

[0081] In block 450, the processor may control one or more motors of the aerial robotic vehicle to govern how the aerial robotic vehicle navigates using the currently set proximity threshold. For example, the processor may send signals to control one or more of the motors (e.g., 125) of the aerial robotic vehicle (e.g., 100, 200) for navigation. The processor may control one or more motors to avoid obstacles while maintaining a distance from obstacles, near a navigational path of the aerial robotic vehicle, according to the proximity threshold (i.e., set in blocks 440 or 445). In some embodiments, the aerial robotic vehicle may continue to operate normally executing user commands and/or a preloaded flight plan relying on the collision avoidance system to prevent approaching any object closer than the current setting of the proximity threshold. In some embodiments, the processor may modify control of the aerial robotic vehicle, such as to adjust or modify a preloaded flight plan to ensure that the aerial robotic vehicle does not approach a detected obstacle closer than the current setting of the proximity threshold.

[0082] FIG. 5 illustrates a method 500 for operating an aerial robotic vehicle according to some embodiments. With reference to FIGS. 1-5, the method 500 may be performed by a processor, such as a processor (220) within a processing device (e.g., 210) of an aerial robotic vehicle (e.g., 100, 200) to detect whether propeller guards (e.g., 250, 350) are installed and set a proximity threshold accordingly in response thereto. In the method 500, the processor may perform operations of blocks 405, 410, 420, 440, 445, and 450, as well as determination block 425, of the method 400 as described above.

[0083] In response to determining that a propeller guard is installed (i.e., determination block 425 =“Yes”), the processor may determine whether a propeller guard (i.e., the propeller guard determined to be installed in determination block 425) meets a predetermined standard in determination block 430.

[0084] In response to determining that the propeller guard does not meet the predetermined standard (i.e., determination block 530 =“No”), the processor may set the proximity threshold to the higher value in block 440. Alternatively, or additionally, the processor may issue a maintenance alert or force maintenance in response to determining that the propeller guard does not meet the

predetermined standard (i.e., determination block 530 =“No”).

[0085] In response to determining that propeller guard meets the predetermined standard (i.e., determination block 530 =“Yes”), the processor may set the proximity threshold to the lower value in block 445.

[0086] FIG. 6 illustrates a method 600 for operating an aerial robotic vehicle according to some embodiments. With reference to FIGS. 1-6, the method 600 may be performed by a processor, such as a processor (220) within a processing device (e.g., 210) of an aerial robotic vehicle (e.g., 100, 200) to detect whether propeller guards (e.g., 250, 350) are installed and set a proximity threshold accordingly in response thereto. In the method 600, the processor may perform operations of blocks 405, 410, 420, 440, 445, and 450 and determination block 425 of the method 400, as well as determination block 530 of the method 500 as described above.

[0087] FIG. 7 illustrates a method 700 for detecting and classifying objects for use in the method 400 according to some embodiments. With reference to FIGS. 1 A-7, the method 700 may be performed by a processor, such as a processor (220) within a processing device (e.g., 210) of an aerial robotic vehicle (e.g., 100, 200) to detect obstacles (e.g., 120) and perform an action in response.

[0088] In block 710, the processor may obtain data from image sensors, such as one or more cameras positioned on the robotic vehicle. Such image data may be stored in local memory for processing, such as buffer memory. [0089] In block 720, the processor may analyze the obtained image data to identify the presence and characteristics of objects in the vicinity of a rotor to determine whether that object is a propeller guard. Such image analysis may involve identifying edges zones of different colors and other types of processes that are typically used to identify objects within images. In some embodiments, the aerial robotic vehicle may be equipped with stereoscopic cameras which may enable the processor to determine the distance to various objects, or parts of objects, using stereoscopy. Determining the location and/or dimensions of objects may generate a file or database of object coordinates in memory that enables the processor to generate a map of objects in subsequent operations.

[0090] Each of the objects that are identified in block 720 may be individually analyzed using image recognition processes. To do so, the processor may implement a loop to individually investigate each object. Thus, in block 730, the processor may select one of the identified objects, and perform object recognition processing on of the image data for the selected object to determine whether the object in a propeller guard in block 740. As described, such image recognition processing may involve comparing image data to the database of known propeller guards to determine whether there is a close match. Such image recognition processes may involve the use of machine learning techniques.

[0091] In determination block 745, the processor may determine whether the object is a propeller guard.

[0092] In response to determining that the selected object is not a propeller guard (i.e., determination block 745 =“No”), the processor may determine whether there is another object within the image data to identify in determination block 755.

[0093] In response to determining that the selected object is a propeller guard (i.e., determination block 745 =“Yes”), the processor may perform a more detailed analysis of the select object to determine whether the propeller guard is damaged and/or meets predetermined standards in block 750. [0094] In determination block 755, the processor may determine whether there is another object within the image data that needs to be analyzed. In response to determining there is another object within the image data to analyze (i.e., determination block 755 =“Yes”), the processor may select another identified object in block 730 and repeat the operations of blocks 740 - 750 as described. When all objects have been analyzed (i.e., determination block 755 =“No”), the processor may proceed to determine whether a propeller guard is installed in determination block 425 of the methods 400, 500, and/or 60 as described.

[0095] As described, the processor (e.g., 220) of the aerial robotic vehicle (e.g., 200) may determine whether an anomaly in a rotor is detected, may determine whether vehicle flight is authorized despite the anomaly based on commands received or data obtained from a remote computing device. In such

embodiments, communications with the aerial robotic vehicle may be

implemented including personal computers, wireless communication devices (e.g., smartphones, etc.), servers, laptop computers, etc., an example of which in the form of a smartphone 800 is illustrated in FIG. 8. With reference to FIGS. 1- 8, a remote computing device 800 may include a processor 802 coupled with the various systems and components. For example, the processor 802 may be coupled to a touch screen controller 804, radio communication elements, speakers and microphones, and an internal memory 806. The processor 802 may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory 806 may 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.

[0096] The touch screen controller 804 and the processor 802 may also be coupled to a touch screen panel 812, such as a resistive-sensing touch screen, capacitive- sensing touch screen, infrared sensing touch screen, etc. Additionally, the display of the remote computing device 800 need not have touch screen capability. The remote computing device 800 may have one or more radio signal transceivers 808 (e.g., Peanut, Bluetooth, Bluetooth LE, ZigBee, Wi-Fi®, radio frequency (RF) radio, etc.) and antennae, the remote computing device antenna 810, for sending and receiving communications, coupled to each other and/or to the processor 802. The radio signal transceivers 808 and the remote computing device antenna 810 may be used with the above-mentioned circuitry to implement the various wireless transmission protocol stacks and interfaces. The remote computing device 800 may include a cellular network wireless modem chip 816 coupled to the processor that enables communication via a cellular network.

[0097] The remote computing device 800 may include a peripheral device connection interface 818 coupled to the processor 802. The peripheral device connection interface 818 may 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 interface 818 may also be coupled to a similarly configured peripheral device connection port (not shown).

[0098] In various embodiments, the remote computing device 800 may include one or more microphones 815. For example, the remote computing device may have microphones 815 that are conventional for receiving voice or other audio frequency energy from a user during a call. The remote computing device 800 may also include speakers 814 for providing audio outputs. The remote computing device 800 may also include a housing 820, constructed of a plastic, metal, or a combination of materials, for containing all or some of the

components. The remote computing device 800 may include a power source 822 coupled to the processor 802, 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 remote computing device 800. The remote computing device 800 may also include a physical button 824 for receiving user inputs (e.g., an input override indicating whether the propeller guard is or is not installed). [0099] Various embodiments illustrated and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and may be used or combined with other embodiments that are shown and described. Further, the claims are not intended to be limited by any example embodiment. For example, one or more of the operations of the methods 400, 500, 600, and/or 700 may be substituted for or combined with another.

[00100] The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of operations in the foregoing embodiments may be performed in any order. Words such as “thereafter,”“then,”“next,” etc. are not intended to limit the order of the operations; these words are used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles“a,”“an,” or“the” is not to be construed as limiting the element to the singular.

[00101] Various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such embodiment decisions should not be interpreted as causing a departure from the scope of the claims. [00102] The hardware used to implement various illustrative logics, logical blocks, modules, and circuits described in connection with various embodiments may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, a plurality of

microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

[00103] In one or more aspects, the functions described may be

implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or non-transitory processor-readable storage medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module or processor-executable instructions, which may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable storage medium and/or computer-readable storage medium, which may be incorporated into a computer program product.

[00104] The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims.

Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the claims.

Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.