Asymmetric can based communication for an aircraft
By adopting a CAN bus redundancy design in the unmanned aerial vehicle, the main flight module and the auxiliary flight module receive different control signals, which solves the problem of stable operation when components fail and improves the safety and reliability of the system.
Patent Information
- Application Number
- CN202211561790.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2017-07-27
- Filing Date
- 2018-07-27
- Publication Date
- 2026-02-03
- Estimated Expiration
- 2038-07-27
AI Technical Summary
Existing unmanned aerial vehicle systems struggle to maintain stable operation when components fail, leading to reduced safety and reliability.
A CAN-based communication system is adopted. Through the redundant design of the main flight module and the auxiliary flight module, two CAN buses are used to receive the main control signal and the auxiliary control signal respectively, ensuring that the other component can continue to work normally when one component fails.
It improves the safety and reliability of unmanned aerial vehicles in the event of component failure, ensuring that the aircraft can continue to operate normally, and even perform safe landing or unloading tasks in the event of failure.
Smart Images

Figure CN116331473B_ABST
Abstract
Description
[0001] This application is a divisional application of the patent application with the application number 201880061953.5 and the filing date of 27 July 2018. TECHNICAL FIELD
[0002] The present application relates to asymmetric CAN based communication for aircraft. BACKGROUND
[0003] Unmanned systems, also referred to as autonomous vehicles, are aircraft capable of traveling without a physically present human operator. Unmanned systems can operate in a remote control mode, in an autonomous mode, or in a partially autonomous mode.
[0004] When an unmanned system operates in a remote control mode, a pilot or driver at a remote location can control the unmanned vehicle through commands sent to the unmanned vehicle via a wireless link. When an unmanned system operates in an autonomous mode, the unmanned system typically moves based on pre-programmed navigation waypoints, dynamic automation systems, or a combination of these. Further, some unmanned systems can operate in both a remote control mode and an autonomous mode, and in some cases can do so simultaneously. For example, a remote pilot or driver can wish to leave navigation to an autonomous system while manually performing another task, such as operating a mechanical system to pick up an object, as an example.
[0005] Various types of unmanned systems exist in a variety of different environments. For example, unmanned systems exist that operate in the air, on the ground, underwater, and in space. Examples include quadcopters and tail-sitter UAVs, among others. Unmanned systems also exist that operate in a hybrid, where multi-environment operation is possible. Examples of hybrid unmanned vehicles include amphibious aircraft that can operate on land and on water, or seaplanes that can land on land and on water. Other examples are possible. SUMMARY
[0006] Example systems and methods can involve an aerial vehicle, such as an unmanned aerial system (UAS), communicating over a controller area network (CAN). The network can include a plurality of CAN nodes connected by two or more CAN buses. The CAN nodes can include a control layer having two or more CAN controllers and a plurality of flight modules controlled by the CAN controllers. The network can also include two or more CAN buses connecting the CAN controllers to the flight modules. The CAN controllers, flight modules, and CAN buses can all perform redundant functions such that the aerial vehicle can function properly if one component of the network fails. Allowing components to fail in this way can make aerial vehicles containing the network safer and more reliable.
[0007] In one example, a system is provided that includes a plurality of flight modules including a primary flight module and a secondary flight module. The secondary flight module is configured to perform functions that are redundant to functions performed by the primary flight module. The system also includes a first controller area network (CAN) controller, a second CAN controller, a first CAN bus configured to send primary control signals from the first CAN controller to the primary flight module and the secondary flight module, and a second CAN bus configured to send secondary control signals from the second CAN controller to the primary flight module and the secondary flight module. During a normal operating state, the primary flight module is configured to perform functions in response to receiving the primary control signals and not in response to receiving the secondary control signals, and the secondary flight module is configured to perform functions in response to receiving the secondary control signals and not in response to receiving the primary control signals.
[0008] In another example, a method is provided that includes sending, by a first CAN controller, primary control signals to a primary flight module and a secondary flight module. The method also includes performing, by the primary flight module and not by the secondary flight module, flight-related functions in response to receiving the primary control signals from the first CAN controller. The method also includes sending, by a second CAN controller, secondary control signals to the secondary flight module and the primary flight module. The method also includes performing, by the secondary flight module and not by the primary flight module, flight-related functions that are redundant to the flight-related functions performed by the primary flight module in response to receiving the secondary control signals from the second CAN controller.
[0009] In another example, a system is provided that includes an aerial vehicle, a plurality of flight modules including a primary flight module and a secondary flight module, a plurality of controller area network (CAN) controllers including a first CAN controller and a second CAN controller, a plurality of processors, and a non-transitory computer-readable medium. The system also includes program instructions stored on the non-transitory computer-readable medium and executable by the plurality of processors to send, by the first CAN controller, a primary control signal to the primary flight module and the secondary flight module. The program instructions also include, in response to receiving the primary control signal from the first CAN controller, executing, by the primary flight module and not by the secondary flight module, a flight-related function. The program instructions also include sending, by the second CAN controller, a secondary control signal to the secondary flight module and the primary flight module. The program instructions additionally include, in response to receiving the secondary control signal from the second CAN controller, executing, by the secondary flight module and not by the primary flight module, a flight-related function that is redundant to the flight-related function executed by the primary flight module.
[0010] The foregoing overview is merely illustrative and is not intended to limit the disclosure in any way. Further aspects, embodiments, and features will become apparent from the following detailed description, taken in conjunction with the accompanying figures and overbiew, and the detailed description serves as an overview of various implementations described in the specification. BRIEF DESCRIPTION OF DRAWINGS
[0011] Figure 1A is a simplified illustration of an unmanned aerial vehicle in accordance with example embodiments.
[0012] Figure 1B is a simplified illustration of an unmanned aerial vehicle in accordance with example embodiments.
[0013] Figure 1C is a simplified illustration of an unmanned aerial vehicle in accordance with example embodiments.
[0014] Figure 1D is a simplified illustration of an unmanned aerial vehicle in accordance with example embodiments.
[0015] Figure 1E is a simplified illustration of an unmanned aerial vehicle in accordance with example embodiments.
[0016] Figure 2 is a simplified block diagram illustrating components of an unmanned aerial vehicle in accordance with example embodiments.
[0017] Figure 3A is a simplified block diagram of a CAN node in accordance with example embodiments.
[0018] Figure 3B is a simplified block diagram of another CAN node in accordance with example embodiments.
[0019] Figure 4is a simplified block diagram of a CAN communication system according to an example embodiment.
[0020] Figure 5A is a simplified block diagram of another CAN communication system according to another example embodiment.
[0021] Figure 5B 、 5C , 5D, 5E, and 5F are simplified diagrams of a CAN communication system in various failed states according to example embodiments.
[0022] Figure 6 is a simplified illustration of an aircraft according to an example embodiment.
[0023] Figure 7 is a simplified illustration of signals received by a CAN node according to an example embodiment.
[0024] Figure 8 is a simplified block diagram of a method according to an example embodiment. DETAILED DESCRIPTION
[0025] Example methods and systems are described herein. Any example embodiments or features described herein are not necessarily to be construed as being preferred or advantageous over other embodiments or features. The example embodiments described herein are not meant to be limiting. It is readily appreciated that certain aspects of the disclosed systems and methods can be arranged and combined in a variety of different configurations, all of which are contemplated herein.
[0026] Further, the specific arrangements illustrated in the figures are not to be construed as limiting. It is to be understood that other embodiments can include more or fewer of each of the elements depicted in a given figure. Furthermore, some of the illustrated elements can be combined or omitted. Additionally, example embodiments can include elements that are not illustrated in the figures.
[0027] I. OVERVIEW
[0028] Example embodiments can include or otherwise involve systems and methods for CAN-based communication. For example, an aircraft can include a plurality of CAN nodes. The CAN nodes can include a control layer having a plurality of CAN controllers. At least two of the CAN controllers can perform redundant functions. The CAN nodes can also include a plurality of flight modules. At least two of the flight modules can also perform redundant functions. The CAN controllers can control the flight modules via two or more CAN buses connected to the same CAN controllers and flight modules. The CAN controllers, flight modules, and CAN buses with redundancy allow one or more components to fail while still allowing the aircraft to operate normally. These redundancies can make the aircraft safer and more reliable.
[0029] CAN-based communication systems can be connected asymmetrically. That is, some flight modules can perform functions in response to control signals received from one CAN controller, but not in response to control signals received from another CAN controller. In other examples, a CAN controller or flight module can transmit signals via one CAN bus, but not via another. This asymmetric interaction within the communication system allows one component to fail without affecting other components of the system. For example, a flight module might fail, causing signals to flood one CAN bus; however, because it is not configured to transmit signals via another CAN bus, the other CAN bus can continue to function normally. Therefore, these asymmetric connections can allow for robust and adaptive systems.
[0030] A CAN-based communication system can operate differently depending on the system's operational state. During normal operation, the primary flight module can receive primary control signals from a first CAN controller via a first CAN bus and secondary control signals from a second CAN controller via a second CAN bus. In response to receiving the primary control signal, and without any additional guidance from any secondary control signals, the primary flight module can perform functions. For example, the Global Positioning System (GPS) can determine the aircraft's current position in response to receiving the primary control signal, or the motor controller can rotate the propellers at a specific speed in response to receiving the primary control signal. Similarly, during normal operation, the secondary flight module can receive both primary and secondary control signals. In response to receiving the secondary control signal, and without any additional guidance from the primary control signal, the secondary flight module can perform functions redundant with those performed by the primary flight module.
[0031] In some examples, one or more CAN nodes in a CAN-based communication system can determine the system's fault state. For instance, the CAN controller, flight module, or CAN bus may stop functioning normally. For example, a CAN node might determine that a particular CAN controller has stopped sending control signals, or that the flight module is providing incorrect data. In response to determining the fault state, multiple actions can be performed depending on the context of the fault. That is, different actions can be performed based on which component has stopped working and how that component failed.
[0032] In some examples, it can be determined that the CAN controller has stopped sending control signals. In response to determining the CAN controller's fault state, different CAN controllers in the system can send additional control signals to the flight module previously controlled by the faulty CAN controller. The flight module, in turn, can perform functions in response to the control signals sent by that different CAN controller.
[0033] In other examples, the system's CAN node can determine the fault state of the flight module. In response to determining the fault state of the flight module, a different flight module can control controllable elements previously controlled by the faulty flight module. For example, a flight module can control one or more motors previously controlled by the faulty flight module.
[0034] In other examples, different flight modules can continue to perform redundant functions previously performed by the failed flight module. Other fault states within the system can be determined by the system, and additional actions can be performed in response to the determination of a fault state. In this way, a CAN-based communication system can adapt to various fault environments and continue to perform functions regardless of the fault state of one or more components of the system. This adaptability can improve the safety and reliability of aircraft incorporating CAN-based communication systems.
[0035] In some examples, CAN-based communication can enable the aircraft to perform actions in response to determining one or more detected fault states of the system. For example, the system can enable the aircraft to land. In other examples, the system can enable the aircraft to return to its home base. In still other examples, the system can enable the aircraft to unload packages carried by the aircraft before landing or returning to its home base. Other actions are also possible. Such actions can prevent damage to the aircraft and save on the costs associated with such damage.
[0036] Reference will now be made in detail to various embodiments, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of this disclosure and the described embodiments. However, this disclosure may be practiced without these specific details. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to unnecessarily obscure various aspects of the embodiments.
[0037] II. Illustrative Unmanned Aerial Vehicles
[0038] Here, the terms "unmanned flight system" and "UAS" refer to any autonomous or semi-autonomous aircraft capable of performing certain functions without the physical presence of a human pilot.
[0039] UAS can take many forms. For example, a UAS can take the form of a fixed-wing aircraft, glider, tailplane, jet aircraft, ducted fan aircraft, lighter-than-air airship (such as an airship or a controllable balloon), rotorcraft (such as a helicopter or a multiplane), and / or ornithopter. Furthermore, the terms "unmanned aircraft," "unmanned aerial vehicle system (UAVS)," or "unmanned aerial vehicle (UAV)" can also be used to refer to a UAS.
[0040] Figure 1A This is a simplified illustration providing various views of the UAS according to an example embodiment. Specifically, Figure 1A An example of a fixed-wing UAS 1100a is shown, which can also be referred to as a fixed-wing aircraft, a passenger plane, a biplane, a glider, or an airplane, etc. As the name suggests, the fixed-wing UAS 1100a has fixed wings 1102 that generate lift based on the wing shape and the forward airspeed of the aircraft. For example, the two wings 1102 may have airfoil cross-sections to generate aerodynamics on the UAS 1100a.
[0041] As depicted, the fixed-wing UAS1100a may include a wing-body or fuselage 1104. The fuselage 1104 may include, for example, control electronics (such as an inertial measurement unit (IMU) and / or an electronic speed controller), batteries, other sensors, and / or payload. The illustrative UAS1100a may also include landing gear (not shown) to assist in controlled takeoff and landing. In other embodiments, other types of UAVs without landing gear are also possible.
[0042] UAS1100a also includes propulsion units 1106 located on the wing 1102 (or fuselage), each propulsion unit including a motor, shaft, and propeller for propelling UAS1100a. Stabilizers 1108 (or fins) may also be attached to UAS1110a to stabilize the yaw (turning left or right) of the UAS during flight. In some embodiments, UAS1100a may also be configured as a glider. For this purpose, UAS1100a can shut down its motors, propulsion units, etc., and glide for a period of time. In UAS1100a, a pair of rotor supports 1110 extend below the wing 1102, and a plurality of rotors 1112 are attached to the rotor supports 1110. The rotors 1112 can be used during hovering mode, where UAS1110a descends to a delivery position or ascends after delivery. In the example UAS1100a, stabilizer 1108 is shown attached to rotor supports 1110.
[0043] During flight, the UAS1100a can control its direction and / or speed of movement by controlling its pitch, roll, yaw, and / or altitude. For example, the stabilizer 1108 may include one or more rudders 1108a for controlling the yaw of the UAS, and the wing 1102 may include one or more elevators for controlling the pitch of the UAS and / or one or more ailerons 1102a for controlling the roll of the UAS. As another example, simultaneously increasing or decreasing the speed of all propellers can respectively increase or decrease the altitude of the UAS1100a.
[0044] Similarly, Figure 1B Another example of a fixed-wing UAS 120 is shown. The fixed-wing UAS 120 includes a fuselage 122, two wings 124 with airfoil cross sections that provide lift to the UAS 120, a vertical stabilizer 126 (or tail) for stabilizing yaw (turning left or right), a horizontal stabilizer 128 (also called an elevator or tail) for stabilizing pitch (tilting up or down), landing gear 130, and a propulsion unit 132, which may include a motor, a shaft, and a propeller.
[0045] Figure 1C An example of a UAS140 with a propeller configured as a thruster is shown. The term "thruster" refers to the fact that the propulsion unit 142 is mounted at the rear of the UAS and "propels" the aircraft forward, in contrast to the propulsion unit being mounted at the front of the UAS. Similar to the provided example... Figure 1A and 1B The description, Figure 1C A common structure used in a propulsion aircraft is depicted, including a fuselage 144, two wings 146, a vertical stabilizer 148, and a propulsion unit 142, which may include a motor, a shaft, and a propeller.
[0046] Figure 1D An example of a tailplane UAS160 is shown. In the illustrated example, the tailplane UAS160 has a fixed wing 162 to provide lift and allow the UAS160 to glide horizontally (e.g., along the x-axis, in a direction approximately perpendicular to the x-axis). Figure 1D (The location shown is indicated). However, the fixed-wing 162 also allows the tailplane UAS160 to take off and land vertically on its own.
[0047] For example, at the launch site, the tailstock UAS160 can be vertically positioned (as shown), with its fins 164 and / or wings 162 resting on the ground and stabilizing the UAS160 in a vertical position. The tailstock UAS160 can then take off by manipulating its propellers 166 to generate upward thrust (e.g., typically along the y-axis). Once at the appropriate altitude, the tailstock UAS160 can use its flaps 168 to reorient itself to a horizontal position, bringing its fuselage 170 closer to the x-axis than to the y-axis. The horizontally positioned propellers 166 can provide forward thrust, allowing the tailstock UAS160 to fly in a manner similar to a typical aircraft.
[0048] The fixed-wing UAS illustrated can have many variations. For example, a fixed-wing UAS may include more or fewer propellers, and / or may utilize ducted fans or multiple ducted fans for propulsion. Furthermore, UAS with more wings (e.g., an "x-wing" configuration with four wings), UAS with fewer wings, or even UAS without wings are also possible.
[0049] As described above, some embodiments may involve other types of UAS besides or as alternatives to fixed-wing UAS. For example, Figure 1E An example of a rotorcraft commonly referred to as a multiplane 180 is shown. The multiplane 180 can also be referred to as a quadcopter because it comprises four rotors 182. It should be understood that the example embodiments may relate to rotorcraft having more or fewer rotors than the multiplane 180. For example, helicopters typically have two rotors. Other examples with three or more rotors are also possible. In this document, the term "multiplane" refers to any rotorcraft having more than two rotors, and the term "helicopter" refers to a rotorcraft with two rotors.
[0050] Referring more specifically to the multiplane 180, four rotors 182 provide propulsion and maneuverability for the multiplane 180. More specifically, each rotor 182 includes blades attached to a motor 184. This configuration allows the rotors 182 to allow the multiplane 180 to take off and land vertically, maneuver in any direction, and / or hover. Furthermore, the pitch of the blades can be adjusted in groups and / or differentially, and allows the multiplane 180 to control its pitch, roll, yaw, and / or altitude.
[0051] It should be understood that the “unmanned” aircraft or UAS mentioned herein can be equally applied to autonomous and semi-autonomous aircraft. In an autonomous implementation, all functions of the aircraft are automated; for example, pre-programmed or controlled via real-time computer functions in response to inputs and / or predetermined information from various sensors. In a semi-autonomous implementation, some functions of the aircraft may be controlled by a human operator, while others are performed autonomously. Furthermore, in some embodiments, the UAS can be configured to allow a remote operator to take over functions that can be autonomously controlled by the UAS in other ways. Additionally, a given type of function can be remotely controlled at one level of abstraction and performed autonomously at another level of abstraction. For example, a remote operator can control the UAS’s high-level navigation decisions, such as specifying that the UAS should travel from one location to another (e.g., from a suburban warehouse to a delivery address in a nearby city), while the UAS’s navigation system autonomously controls more granular navigation decisions, such as a specific route to take between two locations, specific flight controls to achieve the route and avoid obstacles while navigating it, and so on.
[0052] More generally, it should be understood that the example UAS described herein is not limiting. The example embodiments may relate to, be implemented in, or take the form of any type of unmanned aerial vehicle.
[0053] III. Explanatory UAS Components
[0054] Figure 2 This is a simplified block diagram illustrating the components of a UAS200 according to an example embodiment. The UAS200 may take the form of a reference... Figures 1A-1E The UAS system described is in one of the forms of 100, 120, 140, 160, and 180, or is similar in form. However, the UAS200 may also take other forms.
[0055] The UAS200 may include various types of sensors and may include a computing system configured to provide the functions described herein. In the illustrated embodiment, the sensors of the UAS200 include an inertial measurement unit (IMU) 202, multiple ultrasonic sensors 204, and a GPS 206, as well as other possible sensors and sensing systems.
[0056] In the illustrated embodiment, the UAS 200 also includes one or more processors 208. The processor 208 may be a general-purpose processor or a special-purpose processor (e.g., a digital signal processor, an application-specific integrated circuit, etc.). The one or more processors 208 may be configured to execute computer-readable program instructions 212 stored in the data storage 210 and may be executed to provide the functionality of the UAS described herein.
[0057] Data storage 210 may include or take the form of one or more computer-readable storage media that can be read or accessed by at least one processor 208. The one or more computer-readable storage media may include volatile and / or non-volatile storage components, such as optical, magnetic, organic, or other memory or disk storage, which may be wholly or partially integrated with at least one of the one or more processors 208. In some embodiments, data storage 210 may be implemented using a single physical device (e.g., a single optical, magnetic, organic, or other memory or disk storage unit), while in other embodiments, data storage 210 may be implemented using two or more physical devices.
[0058] As described above, data storage 210 may include computer-readable program instructions 212 and possible additional data, such as diagnostic data of UAS 200. Thus, data storage 210 may include program instructions 212 that perform or facilitate some or all of the UAS functions described herein. For example, in the illustrated embodiment, program instructions 212 include a navigation module 214 and a tether control module 216.
[0059] A. Sensor
[0060] In the illustrated embodiment, IMU 202 may include both an accelerometer and a gyroscope, which can be used together to determine the orientation of the UAS 200. Specifically, the accelerometer measures the aircraft's orientation relative to the Earth, while the gyroscope measures the rate of rotation about an axis. IMUs are commercially available in low-cost, low-power packages. For example, IMU 202 may take the form of or include miniaturized microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS). Other types of IMUs may also be utilized.
[0061] In addition to accelerometers and gyroscopes, IMU 202 may include other sensors that can help better determine position and / or help increase the autonomy of UAS 200. Two examples of such sensors are magnetometers and pressure sensors. In some embodiments, the UAS may include a low-power digital 3-axis magnetometer, which can be used to implement a azimuth-independent electronic compass for accurate heading information. However, other types of magnetometers may also be used. Other examples are also possible. Furthermore, note that the UAS may include some or all of the aforementioned inertial sensors as components independent of the IMU.
[0062] The UAS200 may also include a pressure sensor or barometer, which can be used to determine the altitude of the UAS200. Alternatively, other sensors, such as an acoustic altimeter or radar altimeter, can be used to provide altitude indication, which can help improve the accuracy of the IMU and / or prevent IMU drift.
[0063] On the other hand, the UAS200 may include one or more sensors that allow the UAS to sense objects in the environment. For example, in the illustrated embodiment, the UAS200 includes multiple ultrasonic sensors 204. The multiple ultrasonic sensors 204 can determine the distance to an object by generating sound waves and determining the time interval between transmitting the wave and receiving a corresponding echo from the object. Typical applications of ultrasonic sensors for unmanned aerial vehicles or IMUs are low-level altitude control and obstacle avoidance. Ultrasonic sensors can also be used for aircraft that need to hover at a certain altitude or need to be able to detect obstacles. Other systems can be used to determine the presence of nearby objects, sense the presence of nearby objects, and / or determine the distance to nearby objects, such as light detection and ranging (LIDAR) systems, laser detection and ranging (LADAR) systems, and / or infrared or forward-looking infrared (FLIR) systems, etc.
[0064] In some embodiments, the UAS 200 may also include one or more imaging systems. For example, the UAS 200 may utilize one or more static and / or video cameras to capture image data from the UAS's environment. As specific examples, charge-coupled device (CCD) cameras or complementary metal-oxide-semiconductor (CMOS) cameras can be used in unmanned aerial vehicles. Such imaging sensors have a variety of possible applications, such as obstacle avoidance, localization technology, ground tracking for more precise navigation (e.g., by applying optical flow techniques to images), video feedback, and / or image recognition and processing, etc.
[0065] The UAS200 may also include a GPS receiver 206. The GPS receiver 206 may be configured to provide typical GPS data, such as the GPS coordinates of the UAS200. This GPS data can be used by the UAS200 for various functions. Thus, the UAS can use its GPS receiver 206 to aid in navigation to the caller's location, indicated at least in part by GPS coordinates provided by their mobile device. Other examples are also possible.
[0066] B. Navigation and Location Determination
[0067] The navigation module 214 can provide functionality that allows the UAS 200 to move, for example, within its environment and reach a desired location. To this end, the navigation module 214 can control the altitude and / or direction of flight by controlling the mechanical characteristics of the UAS that affect flight (e.g., the speed of its rudder(s), elevator(s), aileron(s), and / or its propeller(s)).
[0068] For example, to navigate the UAS200 to a target location, the navigation module 214 can implement various navigation techniques, such as map-based navigation and location-based navigation. With map-based navigation, a map of the UAS200's environment can be provided, which can then be used to navigate to a specific location on the map. With location-based navigation, the UAS200 may be able to use positioning to navigate in an unknown environment. Location-based navigation may involve the UAS200 building its own environment map and calculating its position on the map and / or the positions of objects in the environment. For example, as the UAS200 moves throughout its environment, it can continuously use positioning to update its environment map. This continuous map-building process can be called simultaneous localization and mapping (SLAM). Other navigation techniques may also be utilized.
[0069] In some embodiments, navigation module 214 may use waypoint-dependent techniques for navigation. Specifically, a waypoint is a set of coordinates that identify a point in physical space. For example, air navigation waypoints may be defined by a latitude, longitude, and altitude. Thus, navigation module 214 can enable UAS 200 to move from one waypoint to another in order to eventually reach its final destination (e.g., the final waypoint in a waypoint sequence).
[0070] On the other hand, navigation module 214 and / or other components and systems of UAS 200 can be configured for "positioning" to more precisely navigate to a target location. More specifically, in some cases, it may be desirable for the UAS to deliver payload 228 at a target location within a threshold distance of the target location (e.g., within a few feet of the target destination). For this purpose, the UAS can use a two-tiered approach, where it uses more general positioning techniques to navigate to a general area associated with the target location, and then uses more refined positioning techniques to identify and / or navigate to the target location within that general area.
[0071] For example, the UAS200 can use waypoints and / or map-based navigation to navigate to a general area of the target destination where payload 228 is delivered. The UAS can then switch to a mode in which it utilizes a positioning process to locate and proceed to a more specific location. For instance, if the UAS200 is to deliver a payload to a user's home, it may need to be substantially close to the target location to avoid delivering the payload to an undesirable area (e.g., to a rooftop, a pool, a neighbor's property, etc.). However, GPS signals may only allow the UAS200 to reach that far (e.g., within a block of the user's home). More precise location determination techniques can then be used to locate the specific target location.
[0072] Once the UAS200 has navigated to the general area of the target delivery location, various types of location determination techniques can be used to pinpoint the location of the target delivery location. For example, the UAS200 may be equipped with one or more sensing systems (such as, for example, an ultrasonic sensor 204, an infrared sensor (not shown), and / or other sensors) that can provide input to the navigation module 214 for autonomous or semi-autonomous navigation to a specific target location.
[0073] As another example, once the UAS200 reaches the general area of the target delivery location (or the general area of a moving object such as a person or their mobile device), the UAS200 can switch to a "fly-by-wire" mode, in which it is at least partially controlled by a remote operator who can navigate the UAS200 to the specific target location. For this purpose, sensor data from the UAS200 can be sent to the remote operator to assist them in navigating the UAS200 to the specific location.
[0074] As another example, the UAS200 may include a module capable of signaling to passersby to request assistance in reaching a specific target delivery location; for example, the UAS200 may display a visual message requesting such assistance on a graphic display, play an audio message or tone indicating the need for such assistance via a speaker, and so on. This visual or auditory message may indicate that assistance is needed in delivering the UAS200 to a specific person or location, and may provide information to help the passerby deliver the UAS200 to that person or location (e.g., a description or picture of the person or location, and / or the name of the person or location), and so on. This feature is useful in scenarios where the UAS cannot use sensing capabilities or another location determination technology to reach a specific target location. However, this feature is not limited to such scenarios.
[0075] In some embodiments, once the UAS 200 reaches the general area of the target delivery location, the UAS 200 can use beacons from a remote device of the user (e.g., the user's mobile phone) to locate the person. Such beacons can take various forms. For example, consider a scenario where a remote device (such as the mobile phone of the person requesting UAS delivery) is capable of emitting directional signals (e.g., via RF signals, light signals, and / or audio signals). In this scenario, the UAS 200 can be configured to navigate by directional signals such as “source locator”—in other words, by determining the location of the strongest signal and navigating accordingly. As another example, a mobile device can emit frequencies within or outside human range, and the UAS 200 can listen to those frequencies and navigate accordingly. As a related example, if the UAS 200 is listening for verbal commands, then the UAS 200 can use verbal statements (such as “I’m here!”) to source the specific location of the person requesting the delivery of the payload.
[0076] In an alternative arrangement, the navigation module can be implemented at a remote computing device that wirelessly communicates with the UAS200. The remote computing device can receive data indicating the operational status of the UAS200, sensor data from the UAS200 allowing it to assess the environmental conditions the UAS200 is encountering, and / or the UAS200's position information. Based on this information, the remote computing device can determine the altitude and / or heading adjustments the UAS200 should make, and / or determine how the UAS200 should adjust its mechanical characteristics (e.g., the speeds of its rudder(s), elevator(s), aileron(s), and / or propeller(s)) to achieve such movement. The remote computing system can then communicate these adjustments to the UAS200 so that it can move in a determined manner.
[0077] C. Communication System
[0078] On the other hand, the UAS200 includes one or more communication systems 218. Communication systems 218 may include one or more wireless interfaces and / or one or more wired interfaces, allowing the UAS200 to communicate via one or more networks. Such wireless interfaces can provide communication under one or more wireless communication protocols, such as Bluetooth, WiFi (e.g., IEEE 802.11), Long-Term Evolution (LTE), WiMAX (e.g., IEEE 802.16), radio-frequency ID (RFID) protocol, near-field communication (NFC), and / or other wireless communication protocols. Such wired interfaces may include Ethernet interfaces, Universal Serial Bus (USB) interfaces, or similar interfaces, for communicating with wired networks via wires, twisted pairs, coaxial cables, optical links, fiber optic links, or other physical connections.
[0079] In some embodiments, the UAS200 may include a communication system 218 that allows for both short-range and long-range communication. For example, the UAS200 may be configured for short-range communication using Bluetooth and long-range communication under the CDMA protocol. In this embodiment, the UAS200 may be configured to operate as a "hotspot," or in other words, as a gateway or proxy between a remote support device and one or more data networks, such as cellular networks and / or the Internet. With this configuration, the UAS200 can facilitate data communication that the remote support device would otherwise be unable to perform independently.
[0080] For example, the UAS200 can provide WiFi connectivity to remote devices and act as a proxy or gateway to a cellular service provider's data network, such as one that can connect to LTE or 3G protocols. The UAS200 can also be used as a proxy or gateway to high-altitude balloon networks, satellite networks, or combinations thereof, where remote devices may otherwise be unable to access these networks.
[0081] D. Power System
[0082] On the other hand, the UAS200 may include multiple power systems 220. Power systems 220 may include one or more batteries for supplying power to the UAS200. In one example, the one or more batteries may be rechargeable and each battery may be recharged via a wired connection between the battery and a power source and / or via a wireless charging system, such as an inductive charging system that applies an external time-varying magnetic field to the internal batteries.
[0083] E. Payload Delivery
[0084] UAS200 can employ various systems and configurations to transport and deliver payload 228. In some embodiments, the payload 228 of a given UAS200 may include, or can take the form of, a "package" designed to transport various goods to a target delivery location. For example, UAS200 may include compartments in which one or more items may be transported. Such packages may transport one or more food items, purchased goods, medical supplies, or any other object(s) having a size and weight suitable for transport by the UAS between two locations. In other embodiments, payload 228 may simply be one or more items being delivered (e.g., any package without items).
[0085] In some embodiments, payload 228 may be attached to the UAS and remain substantially outside the UAS for some or all of the flight conducted by the UAS. For example, during a flight to a target location, the package may be tethered or otherwise releasably attached to the UAS. In embodiments where the package carries cargo under the UAS, the package may include various features that protect its contents from environmental influences, reduce aerodynamic drag on the system, and prevent displacement of the package's contents during flight in the UAS.
[0086] For example, when payload 228 takes the form of a package for transporting goods, the package may include an outer shell made of waterproof cardboard, plastic, or any other lightweight and waterproof material. Furthermore, to reduce drag, the package may have a smooth surface with a pointed front end, thereby reducing the frontal cross-sectional area. Additionally, the sides of the package may taper gradually from a wide bottom to a narrow top, allowing the package to act as a narrow pylon to reduce interference with the UAS(s) wing(s). This can keep some frontal areas and volumes of the package away from the UAS(s) wing(s), thus preventing the package from reducing the lift of the wing(s). Furthermore, in some embodiments, the outer shell of the package may be made of a single piece of material to reduce air gaps or additional material, both of which can increase system drag. Additionally or alternatively, the package may include stabilizers to suppress package flutter. This reduction in flutter can result in less rigidity in the connection between the package and the UAS and can reduce the displacement of the package's contents during flight.
[0087] To deliver the payload, the UAV may include a tether system 221, which may be controlled by a tether control module 216 to lower the payload 228 to the ground while the UAV is hovering above. The tether system 221 may include a tether that is coupled to the payload 228 (e.g., a package). The tether 224 may be wound around a reel of a motor 222 coupled to the UAV (although a passive implementation without a motor is also possible). The motor may be a DC motor (e.g., a servo motor) that can be actively controlled by a speed controller, although other motor configurations are also possible. In some embodiments, the tether control module 216 may control the speed controller to rotate the reel of motor 222, thereby unwinding or retracting the tether and lowering or raising the payload coupling device. In practice, the speed controller may output a desired operating rate of the reel (e.g., a desired RPM), which may correspond to the speed at which the tether system should lower the payload toward the ground. The motor may then rotate the reel to maintain the desired operating rate (or within some permissible range of the operating rate).
[0088] To control the motor via the speed controller, the tether control module 216 can receive data from a speed sensor (e.g., an encoder) configured to convert mechanical position into a representative analog or digital signal. Specifically, the speed sensor may include a rotary encoder, which can provide information related to the rotational position (and / or rotational movement) of the motor shaft or a spool coupled to the motor, etc. Furthermore, the speed sensor may take the form of an absolute encoder and / or an incremental encoder, etc. Thus, in an example embodiment, a rotary encoder can be used to measure the rotation as the motor rotates the spool. In doing so, the rotary encoder can be used to convert the rotational position into an analog or digital electronic signal used by the tether control module 216 to determine the amount of rotation of the spool from a fixed reference angle, and / or into an analog or digital electronic signal representing the new rotational position, etc. Other examples are also possible.
[0089] In some embodiments, the payload coupling assembly (e.g., a hook or another type of coupling assembly) can be configured to secure the payload 228 while lowering it from the UAV via a tether. The coupling device or assembly can also be configured to release the payload 228 via electrical or electromechanical features of the coupling assembly upon reaching the ground. The payload coupling assembly can then be retracted into the UAV by using a motor to wind up the tether.
[0090] In some embodiments, the payload 228 can be passively released once it has been lowered to the ground. For example, the payload coupling assembly may provide a passive release mechanism, such as one or more swing arms adapted to retract into and extend from the housing. The extended swing arms may form hooks to which the payload 228 can be attached. As the release mechanism and payload 228 are lowered to the ground via a tether, gravity on the release mechanism, along with downward inertial forces, can disengage the payload 228 from the hooks, allowing the release mechanism to be pulled up toward the UAV. The release mechanism may also include a spring mechanism that, when there are no other external forces on the swing arms, deflects the swing arms to retract into the housing. For example, a spring may apply a force to the swing arms that pushes or pulls them toward the housing, such that once the weight of the payload 228 no longer forces the swing arms to extend from the housing, the swing arms retract into the housing. Retracting the swing arms into the housing when the release mechanism is pulled up toward the UAV during payload 228 delivery reduces the likelihood of the release mechanism hooking the payload 228 or other nearby objects.
[0091] In another embodiment, the payload coupling assembly may include a hook feature that passively releases the payload when it contacts the ground. For example, the payload coupling assembly may take the form of or include a hook feature whose size and shape are designed to interact with a corresponding attachment feature (e.g., a handle or hole) on a payload in the form of a container or suitcase. The hook may be inserted into the handle or hole of the payload container such that the weight of the payload keeps the payload container secured to the hook feature during flight. However, the hook feature and the payload container may be designed such that when the container contacts the ground and is supported from below, the hook feature slides off the attachment feature of the container, thereby passively releasing the payload container. Other passive release configurations are also possible.
[0092] Active payload release mechanisms are also possible. For example, sensors such as altimeters and / or accelerometers based on atmospheric pressure can help detect the position of the release mechanism (and payload) relative to the ground. Data from the sensors can be transmitted back to the UAS and / or control system via a wireless link and used to help determine when the release mechanism has reached ground level (e.g., by detecting measurements as a ground impact characteristic using accelerometers). In other examples, the UAS can determine that the payload has reached the ground based on a threshold low downward force detected by a weight sensor on the tether and / or a threshold low measurement based on the power drawn by the winch during payload descent.
[0093] In addition to or as an alternative to tethered delivery systems, other systems and technologies for delivering payloads are possible. For example, the UAS200 may include an airbag descent system or a parachute descent system. Alternatively, the UAS200 carrying the payload may simply land at the delivery location. Other examples are also possible.
[0094] IV. Illustrative CAN-based Communication
[0095] Figure 3A This is a block diagram of a Controller Area Network (CAN) node included within a system 300 according to an example embodiment. In this example, the CAN node includes a CAN controller 302. In this example, the CAN node may be included as part of a control layer that controls multiple modules. The controller 302 includes a processor and a computer-readable medium. The computer-readable medium may have instructions stored thereon that, when executed by the processor, cause the CAN controller 302 to perform functions. For example, the instructions may determine control signals that the CAN node sends to another CAN node within the system 300.
[0096] Controller 302 is connected to other CAN nodes of system 300 via transceivers 306 and 308. In this example, and throughout all figures, each transceiver is labeled "XCRV". Although transceivers 306 and 308 are depicted as separate from CAN controller 302, it should be understood that in some embodiments, the CAN controller may include one or more transceivers. Furthermore, although only two transceivers are depicted in this example, additional transceivers may be connected to CAN nodes.
[0097] In this example, transceiver 306 allows bidirectional communication with other CAN nodes of system 300. That is, CAN controller 302 can receive signals via transceiver 306 and also transmit signals via transceiver 306. Conversely, transceiver 308 is depicted as allowing only unidirectional communication. For example, CAN controller 302 can be configured to receive signals via transceiver 308 without transmitting signals.
[0098] In this example, and throughout the detailed description, reference is made to signals in a CAN-based communication system. Those skilled in the art will readily understand that such signals can refer to high-speed CAN signals, low-speed CAN signals, or other signals configured to transmit information from one CAN node to another. Furthermore, such signals can transmit information using a basic frame format, an extended frame format, or any format that includes a structure that allows the receiving CAN node to identify a particular signal source or type.
[0099] Figure 3BThis is a block diagram of another CAN node that may be included within system 300 according to an example embodiment. In this example, CAN node 310 includes flight module 312, transceivers 316 and 320, and connectors 314 and 318. Flight module 312 includes a processor and a computer-readable medium. The computer-readable medium may have instructions stored thereon that cause flight module 312 to perform functions. For example, the instructions may determine a flight-related function to be performed based on signals received by transceivers 316 and 320, and may cause flight module 312 to perform that function. Flight-related functions may include acquiring and / or sending sensor data to another CAN node of system 300. In other examples, flight-related functions may include operating sensors, actuators, motors, servo systems, propellers, communication terminals, or other controllable elements of the aircraft. In some examples, signals received at the transceiver may include data from a CAN controller (such as those mentioned above). Figure 3A The control signals sent by the CAN controller 302 described herein. The signals may also include signals sent by other flight modules within the system 300.
[0100] Flight modules within system 300 (such as flight module 312) may control or include motors, servo systems, air sensors, weather sensors, GPS sensors, battery systems, package systems, or other components of the aircraft. Some of these may perform functions critical to the flight of the aircraft. For example, the system's motors, servo systems, and air sensors may be essential for the aircraft to maintain flight. Flight modules that control or include such components of the aircraft may be referred to as "flight-critical modules." Other flight modules may not be essential for flight. For example, indicator lights may not be absolutely necessary for the aircraft to remain airborne. Flight modules that control or include such components may be referred to as "non-flight-critical modules."
[0101] In some examples, certain flight-critical modules can perform functions that are redundant with those performed by other flight-critical modules. This way, if one flight-critical module fails, another module can perform the same function to keep the aircraft airborne or to allow the aircraft to operate as normal. Alternatively, the module performing the redundant function can enable the aircraft to land safely.
[0102] Figure 4 This is a simplified block diagram of a CAN-based communication system 400 according to an example embodiment. System 400 includes CAN nodes forming a control layer 402 and multiple flight modules. The control layer includes a first CAN controller 404 and a second CAN controller 406. System 400 additionally includes CAN buses 416 and 418 connecting CAN controllers 404 and 408 to flight modules 412 and 414.
[0103] In this example, the first CAN controller 404 is configured to control one or both of flight modules 412 and 414 depending on the operating state of system 400. For example, in normal operation, the first CAN controller 404 can be configured to exclusively control flight module 412 via CAN bus 416, although CAN bus 418 can send signals from the first CAN controller 404 to flight module 414 in normal operation. During normal operation, although flight module 414 can receive control signals from both CAN controllers 404 and 406, flight module 414 can be configured to perform functions only in response to control signals received from the second CAN controller 406. Similarly, during normal operation, flight module 412 can be configured to perform functions only in response to control signals received from the first CAN controller 404.
[0104] In this example, flight module 412 is configured to transmit flight signals via CAN bus 416 but not via CAN bus 418, and flight module 414 is configured to transmit flight signals via CAN bus 418 but not via CAN bus 416. However, CAN controllers 404 and 406 can receive flight signals from both flight modules 412 and 414 because both CAN controllers are connected to two CAN buses. Thus, even if one CAN controller fails, the other CAN controller can still receive flight signals from both flight modules 412 and 414.
[0105] As mentioned above Figure 3B As described, some flight modules can perform functions redundant with other flight modules. In this example, flight module 414 can perform functions redundant with those performed by flight module 412. Therefore, flight module 412 can be referred to as the primary flight module, and flight module 414 can be referred to as the secondary flight module. In this way, system 400 can have multiple redundancy points. If the first CAN controller 404 fails, the second CAN controller 406 can control flight modules 412 and 414, and if flight module 412, as the primary flight module, fails, flight module 414, as the secondary flight module, can continue to perform its functions. Additional example embodiments are described below, illustrating various environments in which the CAN-based communication system can operate.
[0106] In this example and the examples below, the various CAN nodes of the system are asymmetrically connected. That is, the CAN nodes are connected such that they can receive and transmit signals via one CAN bus, but can only receive signals from another CAN bus. For example, flight module 412 can transmit and receive signals via CAN bus 416, but can only receive signals via CAN bus 418. Similarly, flight module 414 can transmit and receive signals via CAN bus 418, but can only receive signals via CAN bus 416. Controllers 404 and 406 are similarly connected to CAN buses 416 and 418. In this way, if one CAN node fails, causing it to continuously transmit signals through one CAN bus and overwhelm or interfere with other signals on that CAN bus, the other CAN bus can continue to transmit signals between the CAN nodes.
[0107] Figure 5A This is a simplified block diagram of a CAN-based communication system 500 according to an example embodiment. System 500 includes a control layer 402 and multiple flight modules. The control layer 402 includes the above-mentioned... Figure 4 The CAN controllers 404 and 406 are described, and additionally include CAN controller 508. The flight module includes flight modules 522 and 524 as non-flight-critical modules and flight module 520 as a flight-critical module, as well as the above-mentioned... Figure 4 Modules 412 and 414 are described. Although only three CAN controllers and five flight modules are depicted in Figure 5, those skilled in the art will readily understand that additional controllers or modules may be included within the system 500.
[0108] System 500 also includes the above information. Figure 4 The CAN buses 416 and 418 are described. In this example, CAN bus 416 connects CAN controllers 404, 508, and 406 and each of flight modules 522, 524, 520, 412, and 414. CAN bus 418 connects CAN controllers 404, 508, and 406 and each of flight modules 520, 412, 414, and 524, but not flight module 522, which is a non-flight-critical module. Therefore, CAN bus 418 can have fewer potential points of failure than CAN bus 416. For example, flight module 522 may fail, causing it to flood CAN bus 416 with signals, making it difficult for other CAN nodes in the system to interpret signals within system 500. However, such a failure will not affect the operation of CAN bus 418, and flight modules 520, 524, 412, and 414 can operate based on signals received from CAN bus 418, not on signals received from CAN bus 416.
[0109] Although in this example, flight module 522 is depicted as receiving control signals only via CAN bus 416, it should be understood that each flight module can connect to every CAN bus of the system. In other examples, several flight modules may connect to only one CAN bus and not to the other. In other examples, each non-flight-critical module can be configured in the same way as module 424, where module 424 is configured to receive signals via both CAN bus 416 and CAN bus 418, but only transmit flight signals via CAN bus 416. Other configurations of the flight modules are also possible.
[0110] Figure 5B This is a simplified block diagram of a CAN-based communication system 500 in which one of the CAN controllers has failed. In this example, the CAN controller 508 has failed. CAN controller failures can include transceiver failures or processor failures, but other types of failures are also possible. In this example, the CAN controller 508 has failed, preventing it from sending control signals.
[0111] In the normal operating state of system 500, CAN controller 404 and CAN controller 508 can operate primarily on CAN bus 416. That is, they can both receive and transmit signals via CAN bus 416, and receive signals only via CAN bus 418. Because two CAN controllers operate primarily on CAN bus 416, they can coordinate signals to control the flight modules. For example, some flight modules can assign higher priority to control signals sent from CAN controller 404, while other flight modules can assign higher priority to control signals sent from CAN controller 508. In other examples, CAN controller 404 can send a predetermined set of control signals, while CAN controller 508 can send another predetermined set of control signals. In additional examples, CAN controller 404 can send only control signals for controlling certain flight modules (such as flight modules 520 and 412), while CAN controller 508 can send only control signals for controlling other flight modules (such as flight modules 522 and 524). In other examples, the flight modules can translate commands received from CAN controllers 404 and 508 into a single actionable command. In these examples, the flight module can use an intermediate value selection algorithm to combine these commands, although other algorithms are also possible.
[0112] In this example, system 500 has encountered a fault state because CAN controller 508 cannot send control signals to the flight modules. However, because CAN controller 404 operates on CAN bus 416, CAN controller 404 can control each flight module as if CAN controller 508 were operating normally. For example, in response to determining the fault state of CAN controller 508, CAN controller 404 can send additional control signals that CAN controller 508 would send under normal conditions. In other examples, the CAN controller can modify its control signals to control each flight module. In other examples, the flight module can determine the fault state of CAN controller 508 and, in response to determining the fault state of CAN controller 508, can assign higher priority to control signals received from CAN controller 404. In this way, system 500 can provide control signals to each flight module as described above. Figure 4 The described system 400 provides additional redundancy.
[0113] Determining the fault state of CAN controller 508 can include receiving data from CAN nodes of system 500 (such as CAN controller 404 or flight modules 522, 524, 520, 412, or 414) indicating that CAN controller 508 has not sent a control signal for a certain period of time. For example, if CAN controller 508 has not sent a control signal for a period of time that meets or exceeds a control signal waiting threshold, CAN controller 404 can begin controlling the flight module previously controlled by CAN controller 508 as if CAN controller 508 were operating normally. Other methods of determining the fault state of CAN nodes are also possible.
[0114] Figure 5C This is a simplified block diagram of a CAN-based communication system 500 where two of the CAN controllers have failed. In this example, CAN controllers 404 and 508 have failed. That is, neither CAN controller 404 nor CAN controller 508 can send control signals to the flight modules. Because CAN controllers 404 and 508 have failed, neither can send control signals, therefore flight modules 520, 412, and 414 can only receive control signals from CAN controller 406, and flight module 522 cannot receive any control signals at all. The flight modules can determine the fault state of CAN controllers 404 and 508 individually or jointly. In other examples, another CAN controller in system 500 can determine the fault state of the other CAN controller. In this example, CAN controller 406 can determine the fault state of CAN controllers 404 and 508.
[0115] In response to determining a fault state, CAN controller 406 can send control signals to flight modules 520, 412, and 414 via CAN bus 418, causing CAN controller 406 to control flight modules 520, 412, and 414. In some examples, CAN controller 406 can send additional control signals in response to determining a fault state. Such additional control signals can instruct flight modules 520, 412, and 414 that they should comply with control signals received via CAN bus 418. For example, the additional control signals can have a higher priority than control signals sent before determining the fault state of CAN controllers 404 and 508. In other examples, control signals can indicate the fault state of CAN controllers 404 and 508 to the flight modules, and the flight modules can independently determine and perform functions in response to receiving control signals from CAN controller 406. In other examples, the additional control signals can remain unchanged, and the flight modules can determine the fault state.
[0116] In this example, flight modules 522 and 524 do not receive any control signals from CAN controllers 404 and 406. Flight modules 522 and 524 can be configured to determine, individually or jointly, that no signal has been received. In response to determining that no control signal has been received, both flight modules 522 and 524 can revert to their default operating state. In the default operating state, flight modules 522 and 524 can rely on instructions stored in memory associated with the flight modules. For example, in the example where flight modules 522 and 524 include flight sensors, instructions can be executed by the processor associated with flight modules 522 and 524 to cause the flight modules to continue transmitting flight sensor data despite the lack of control signals. Each flight module of system 500 can similarly operate in its default operating state based on the environment of system 500.
[0117] In this example, even though CAN controllers 404 and 508 fail, the flight module can continue to transmit signals via CAN bus 416. For example, one or more of flight modules 520, 412, or 414 can act as a relay station between CAN controller 406 and flight module 522. Furthermore, flight modules 522, 524, 520, and 412 can continue to transmit flight signals to CAN controller 406 via CAN bus 416. CAN controller 406 can use the flight signals received from the flight modules to determine the control signals sent to the flight modules via CAN bus 418.
[0118] Although CAN controllers 404 and 508 are depicted in this example as unable to transmit control signals via CAN bus 416, a fault state of the CAN controllers of system 500 could include the inability to receive signals. For example, a transceiver associated with CAN controller 404 may fail, causing CAN controller 404 to be unable to receive signals via CAN bus 416. Controller 404 may send a signal to other CAN nodes of system 500 indicating that it cannot receive signals via CAN bus 416. In response to receiving such a signal, another CAN controller (such as CAN controller 406) or flight module (such as flight module 414) may act as a relay station and send a signal to CAN controller 404 via CAN bus 418.
[0119] Figure 5D This is a simplified block diagram of a CAN-based communication system 500 in which one of the CAN controllers has failed. In this example, CAN controller 406 has failed, preventing it from sending control signals via CAN bus 418. CAN controllers 404 and 508 are functioning normally, allowing them to send and receive signals via CAN bus 416, while also receiving other signals via CAN bus 418. Thus, flight module 522, being a non-flight-critical module, can function normally because it operates only on CAN bus 416, and flight modules 520 and 412, being flight-critical modules, can also function normally because they are configured to perform functions in response to signals received via CAN bus 416.
[0120] In response to determining a fault state of CAN controller 406, CAN controller 404, CAN controller 508, or both may send additional control signals to control flight module 414. Flight module 414 may continue to send flight signals via CAN bus 418, and CAN controllers 404 and 508 may receive flight signals. In other examples, CAN controllers 404 and 508 may not send additional signals. Instead, because flight module 414 can perform functions redundant with those performed by flight module 412, flight module 414 may simply perform the function in response to receiving a control signal directed to flight module 412 via CAN bus 416.
[0121] Figure 5EThis is a simplified block diagram of a CAN-based communication system 500 where one of the CAN buses has failed. In this example, CAN bus 416 fails, preventing the CAN nodes of system 500 from sending or receiving signals via CAN bus 416. As a result, CAN controllers 404 and 508 cannot send control signals, flight module 522 (a non-flight-critical module) cannot receive or send signals, and flight modules 520, 522, and 412 can only receive signals via CAN bus 418 but cannot send signals. In this example, only flight module 414 can operate normally. Thus, the aircraft associated with system 500 may have to land.
[0122] The controller 406 can determine the fault state of bus 416 by determining that it has not received any signal via bus 416 within a signal waiting threshold time. In response to determining the fault state, the CAN controller 406 can send control signals to flight modules 520 and 412. Because the controller of system 500 can determine the control signals based on signals received from the flight modules (such as sensor signals), the control signals can simply instruct the flight modules to perform predetermined actions. For example, the control signals can instruct the flight modules to perform a landing function.
[0123] Figure 5F This is a simplified block diagram of a CAN-based communication system 500 where one of the CAN buses has failed. In this example, the CAN bus 418 fails, preventing any CAN node in system 500 from sending or receiving signals via CAN bus 418. As a result, the CAN controller 406 cannot send control signals, and the flight module 414 can only receive signals via CAN bus 418. In this example, CAN controllers 404 and 508, as well as flight modules 522, 524, 520, and 412, can operate normally.
[0124] CAN controller 404, CAN controller 508, or both can determine a fault state of bus 418 by confirming that they have not received any signal via bus 418 within a signal waiting threshold time. In response to confirming the fault state, CAN controllers 404 and 508 can send control signals to flight module 414. Because the controllers of system 500 can determine control signals based on signals received from flight modules (such as sensor signals), the control signals can be based on signals received from flight modules 522, 524, 520, and / or 412. Because more controllers and flight modules can operate primarily on CAN bus 416 rather than CAN bus 418, the aircraft associated with system 500 can continue to operate despite a fault in CAN bus 416.
[0125] Despite Figures 4-5FOnly one set of redundant flight modules (flight modules 412 and 414) is depicted, but it should be understood that several flight modules can perform functions that are redundant with those performed by other flight modules in the system. For example, system 500 may include additional flight modules that perform functions that are redundant with those performed by flight module 520. In this way, even in the event of a CAN bus failure, such as CAN bus 416, the aircraft associated with system 500 can remain airborne or even operate normally. However, the CAN controller can send control signals configured to mitigate the risks associated with additional failures in system 500, such as control signals that cause the flight modules to land the aircraft.
[0126] Figure 6 This is a top view of an aircraft 600 according to an example embodiment. In this example, the aircraft 600 includes control areas 610, 612, 614, 616, and 618. Control area 610 includes a wing 602 having a plurality of propellers 604 and a plurality of ailerons 606. Control areas 616 and 618 each include a plurality of propellers 604, and control areas 612 and 614 each include a plurality of propellers 604 and a stabilizer 608. These components may be associated with a CAN node of the aircraft 600's CAN-based communication system. For example, each control area may include the components described above. Figures 5A-5F The system 500 described has one or more CAN nodes. Because the propeller, ailerons, and stabilizer can directly affect whether the aircraft 600 can stay airborne, these components can be controlled by the flight-critical module of the CAN-based communication system.
[0127] In some examples, CAN-based communication can enable aircraft 600 to perform actions in response to determining one or more detected fault states of the system. For example, the system can enable aircraft 600 to land. In other examples, the system can enable aircraft 600 to return to its home base. In still other examples, the system can enable aircraft 600 to unload packages carried by the aircraft before landing or returning to its home base. Other actions are also possible.
[0128] As mentioned above Figures 5A-5F As described, certain fault states in the CAN-based communication system may prevent flight-critical modules from sending or receiving signals. Flight modules may also fail independently. For example, one or more of the propellers 604 of the aircraft 600 may malfunction.
[0129] In the example scenario, the flight module associated with control area 614 may malfunction. Due to the malfunction, one or more of the propellers 604 in control area 614 may cease operation, thereby generating a pitching moment about the central axis of the aircraft 600.
[0130] One or more CAN nodes in the system can determine the fault state of the flight module. For example, the CAN controller can determine that the flight module has stopped transmitting signals, thus determining a fault state. In other examples, sensors can determine the fault. For example, a position sensor can determine that the aircraft 600 is tilting toward the inoperable propeller of control area 614. In response, one or more CAN controllers can send control signals to the flight modules associated with control areas 610, 612, 616, and 618, instructing the flight modules to compensate for the inoperable propeller and to descend slowly for landing. In other example scenarios, redundant flight modules can be instructed to take over control of control area 614.
[0131] The flight-related functions to be performed in response to determining the fault state of aircraft 600 can be determined based on which component has encountered a fault state and the probability of failure of other components. For example, one or more CAN controllers can determine a statistically significant fault probability metric, and control aircraft 600 to continue performing its mission as long as the determined fault probability metric remains below a first fault probability threshold, and control aircraft 600 to land if the fault probability metric meets or exceeds the threshold. Different actions can be based on different fault probability thresholds. For example, returning to home base can be associated with a second threshold, while dropping off packages carried by the aircraft can be associated with a third threshold. Other actions and thresholds are also possible.
[0132] The failure probability metric can be calculated based on the failure probabilities associated with existing components of the aircraft 600. For example, an object avoidance sensor might have a failure probability of once in 1,000 flight hours, a CAN bus might have a failure probability of once in 500,000 flight hours, and a CAN controller might have a failure probability of once in 20,000 flight hours. Other components may have different failure probabilities. The failure probability metric can be based on each of these values and can be adjusted when a component fails. For example, if a flight module fails, the failure probability metric can be adjusted to reflect that the flight module has failed. Furthermore, the metric can additionally assign different weights to various components. For example, the CAN bus could be assigned more weight than the CAN controller, the CAN controller could be assigned more weight than flight-critical modules, and flight-critical modules could be assigned more weight than non-flight-critical modules. Redundant components can also be assigned different weights. For example, a triple-redundant flight module could be assigned less weight than a double-redundant flight module. Other methods for calculating the failure probability metric are also possible.
[0133] Figure 7Several signals according to an example embodiment are illustrated. As described above, determining the fault state of the CAN controller or flight module may include receiving signals from the CAN bus and analyzing the received signals. For example, the CAN controller may anticipate receiving signal 700 between time t1 and t2. For example, the anticipated signal may specify an identifier for a particular flight module or a specific message identifier.
[0134] Alternatively, the CAN controller can receive signals such as signal 702, which simply includes noise centered on the common voltage of the CAN-based communication system. In other examples, the CAN controller can receive signals that deviate from the expected signal, such as signal 704. In either case, the CAN controller can determine that the flight module has encountered a fault condition and respond as described above.
[0135] It should be understood that although signals 700 and 704 describe high-speed CAN signaling, low-speed CAN signaling or other types of signaling can also be used.
[0136] Figure 8 This is a flowchart illustrating example method 800. Figure 8 The method shown can be performed by any system described above with reference to Figures 3-6.
[0137] In addition, for Figure 8 The flowcharts illustrate the functionality and operation of one possible implementation of this embodiment, along with other processes and methods disclosed herein. In this context, blocks may represent modules, segments, or portions of program code, which includes one or more instructions executable by a processor to perform specific logical functions or steps in a process. The program code may be stored on any type of computer-readable medium, such as storage devices including disks or hard disks. Computer-readable media may include non-transitory computer-readable media, such as short-term data storage media like register memory, processor cache, and random access memory (RAM). Computer-readable media may also include non-transitory media, such as auxiliary or persistent long-term storage like read-only memory (ROM), optical disks or magnetic disks, and optical disc read-only memory (CD-ROM). Computer-readable media may also be any other volatile or non-volatile storage system. For example, a computer-readable medium may be considered a computer-readable storage medium, a tangible storage device, or other article of manufacture.
[0138] Furthermore, regarding the methods and other processes and methods disclosed herein, Figure 8Each block in the diagram can represent a circuit that is wired to perform a specific logical function in the process.
[0139] Block 802 can be executed to send main control signals to the main flight module and auxiliary flight modules (such as flight modules 412 and 414) via a first CAN controller (such as CAN controller 404).
[0140] Block 804 can be executed in response to receiving a master control signal from the first CAN controller, so that the master flight module performs flight-related functions instead of the auxiliary flight module.
[0141] Block 806 can be executed to send auxiliary control signals to the auxiliary flight module and the main flight module via a second CAN controller (such as CAN controller 406).
[0142] Block 808 can be executed in response to receiving an auxiliary control signal from the second CAN controller, performing flight-related functions redundant with those performed by the main flight module instead of the main flight module.
[0143] In some embodiments, method 800 may further include receiving flight signals from a primary flight module and a secondary flight module by a first CAN controller. The method may further include determining additional primary control signals by the first CAN controller based on the received flight signals. The method may further include receiving flight signals from the secondary flight module and the primary flight module by a second CAN controller. The method may further include determining additional secondary control signals by the second CAN controller based on the received flight signals.
[0144] In these embodiments, during normal operation, the first CAN controller can determine additional main control signals based on flight signals received from the main flight module, but not on flight signals received from the auxiliary flight module. Furthermore, during normal operation, the second CAN controller can determine additional auxiliary control signals based on flight signals received from the auxiliary flight module, but not on flight signals received from the main flight module.
[0145] In some embodiments, method 800 may further include determining a fault state of the primary flight module. The method may also include, in response to determining the fault state of the primary flight module, a first CAN controller and a second CAN controller determining additional control signals based on flight signals received from the secondary flight module, but not based on flight signals received from the primary flight module.
[0146] In some embodiments, method 800 may further include sending a third control signal to the master flight module by a third CAN controller, such as controller 508, wherein the third control signal is redundant with the master control signal sent by the first CAN controller. The method may further include determining a fault state of the first CAN controller. Determining a fault state of the first CAN controller may include determining that the first CAN controller has stopped sending the master control signal. The method may further include, in response to determining a fault state of the first CAN controller, modifying the third control signal by the third CAN controller such that the master flight module continues to perform flight tasks as if the first CAN controller were still sending the master control signal.
[0147] In some embodiments, the primary flight module and the secondary flight module may be included in a plurality of flight-critical modules. In these embodiments, method 800 may further include determining the fault state of a non-flight-critical module. The method may further include, in response to determining the fault state of a non-flight-critical module, the first CAN controller and the second CAN controller continuing to transmit primary control signals and secondary control signals, respectively.
[0148] In some embodiments, method 800 may further include determining a fault state of a first CAN bus, wherein the first CAN bus is configured to send a master control signal from a first CAN controller to a master flight module. The method may further include, in response to determining the fault state of the first CAN bus, the master flight module performing flight-related functions based on control signals sent by a second CAN controller via a second CAN bus.
[0149] V. Conclusion
[0150] The specific arrangements shown in the accompanying drawings should not be considered limiting. It should be understood that other embodiments may include more or fewer of each element shown in a given figure. Furthermore, some of the elements shown may be combined or omitted. Additionally, exemplary embodiments may include elements not shown in the figures.
[0151] Furthermore, while various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for illustrative purposes and not intended to be limiting; the true scope and spirit are indicated by the appended claims. Other embodiments may be utilized and other changes may be made without departing from the spirit or scope of the subject matter presented herein. It will be readily understood that, as generally described herein and illustrated in the accompanying drawings, the various aspects of this disclosure can be arranged, substituted, combined, separated, and designed in a variety of different configurations, all of which are contemplated herein.
[0152] In this document, the term flight operation includes any operation or flight-related function performed by an aircraft or system, including actions performed by any sensor, actuator, processor, module, or component of the aircraft or system during flight, or actions performed directly or in conjunction with the flight of the aircraft or system.
Claims
1. A method comprising: A statistical failure probability metric for an aircraft is determined based on multiple failure probabilities, wherein each of the multiple failure probabilities represents the probability that a corresponding CAN node among the multiple controller area network (CAN) nodes of the aircraft will fail within a given time range of the aircraft, and wherein determining the statistical failure probability metric includes weighting the corresponding failure probability of the first CAN node based on the fact that the first CAN node among the multiple CAN nodes is at least dual redundant, unlike the corresponding failure probabilities of the non-redundant CAN nodes among the multiple CAN nodes. The aircraft's actions are performed based on statistical failure probability measurements; The first CAN node transmits signals via a CAN bus connected to the plurality of CAN nodes; Based on the signal received from the first CAN node, the second CAN node among the plurality of CAN nodes determines the fault status of the first CAN node; Based on the determined fault state of the first CAN node, the statistical fault probability metric of the aircraft is adjusted, wherein the adjusted statistical fault probability metric indicates a reduction in redundancy associated with the first CAN node caused by the fault state of the first CAN node. Determine whether the adjusted statistical failure probability metric of the aircraft meets or exceeds the failure probability threshold; and In response to the determination that the adjusted statistical failure probability metric of the aircraft meets or exceeds the failure probability threshold, the CAN controller changes the aircraft's actions.
2. The method according to claim 1, wherein, Determining the statistical failure probability metric involves determining the statistical failure probability metric based on the failure probability of multiple components of the aircraft associated with the multiple CAN nodes.
3. The method according to claim 2, further comprising: The probability of failure of the aircraft's multiple components is determined based on the number of flights associated with each of the multiple components.
4. The method according to claim 1, further comprising: Determine the type of the aircraft component corresponding to the first CAN node, wherein determining the adjusted statistical failure probability metric includes determining the adjusted statistical failure probability metric based on the type of the component corresponding to the first CAN node.
5. The method according to claim 4, wherein, The adjusted statistical failure probability metric is determined based on the type of the component corresponding to the first CAN node, including whether the first CAN node is a flight-critical flight module.
6. The method according to claim 4, wherein, The first CAN node is triple redundant before experiencing a failure state of the first CAN node, and the adjusted statistical failure probability metric is determined based on the type of the component corresponding to the first CAN node, including determining the adjusted statistical failure probability metric based on determining that the redundancy associated with the first CAN node is reduced to dual redundancy after experiencing a failure state of the first CAN node.
7. The method according to claim 6, wherein, The adjusted statistical failure probability metric is determined based on the fact that the redundancy associated with the first CAN node is reduced to dual redundancy after experiencing a failure state of the first CAN node. This includes determining that the first CAN node was triple redundant before experiencing a failure state of the first CAN node and is associated with dual redundancy after experiencing a failure state of the first CAN node. The first CAN node is weighted more in the adjusted statistical failure probability metric than when the statistical failure probability metric is determined.
8. The method according to claim 1, wherein, The failure probability threshold is one of a plurality of failure probability thresholds, wherein each of the plurality of failure probability thresholds corresponds to a different action of the aircraft, and wherein changing the action of the aircraft includes changing the action of the aircraft based on which of the plurality of failure probability thresholds is satisfied or exceeded by an adjusted statistical failure probability metric.
9. The method according to claim 8, wherein, Changing the aircraft's actions includes landing the aircraft.
10. The method according to claim 8, wherein, The aircraft's actions include returning it to base.
11. A system comprising: Aircraft; Multiple Controller Area Network (CAN) nodes, including a first CAN node and a second CAN node; Multiple processors; Non-transitory computer-readable medium; as well as Program instructions, which are stored on the non-transitory computer-readable medium and are executable by the plurality of processors to perform the method of any one of claims 1-10.
12. A system comprising: Multiple flight modules, including a primary flight module and an auxiliary flight module, wherein the primary flight module and the auxiliary flight module are configured to perform functions redundantly, such that when the primary flight module fails, the redundant functions continue to enable the system to perform flight operations; First controller local area network (CAN) controller; Second CAN controller; A first CAN bus is configured to send main control signals from the first CAN controller to the main flight module and the auxiliary flight module; and The second CAN bus is configured to send auxiliary control signals from the second CAN controller to the main flight module and the auxiliary flight module; in, During normal operation, the primary flight module is configured to perform functions in response to receiving the primary control signal, but not in response to receiving the secondary control signal. The auxiliary flight module is configured to perform functions in response to receiving the auxiliary control signal, but not in response to receiving the main control signal. The first CAN controller is further configured to control the auxiliary flight module in response to determining a fault state of the second CAN controller, and the second CAN controller is further configured to control the auxiliary flight module in response to determining a fault state of the first CAN controller.
13. The system according to claim 12, wherein, The redundancy function is configured to trigger flight operations during normal operation.
14. The system according to claim 12, wherein, The first CAN controller is further configured to receive the auxiliary control signal transmitted by the second CAN controller via the second CAN bus, and wherein the second CAN controller is further configured to receive the main control signal transmitted by the first CAN controller via the first CAN bus.
15. The system according to claim 12, wherein, The plurality of flight modules include non-flight critical modules and a plurality of flight critical modules, wherein the plurality of flight critical modules include the main flight module and the auxiliary flight module.
16. The system according to claim 15, wherein, The first CAN controller is also configured to control the non-flight critical module, and wherein the second CAN controller is not configured to control the non-flight critical module.
17. The system according to claim 13, wherein, Each of the first CAN controller, the second CAN controller, and the plurality of flight modules is included in a plurality of CAN nodes of the system, wherein a CAN node of the plurality of CAN nodes transmits signals via the first CAN bus but not via the second CAN bus, and wherein other CAN nodes of the plurality of CAN nodes transmit signals via the second CAN bus but not via the first CAN bus.
18. The system of claim 12 further includes a third CAN controller configured to control the main flight module, the third CAN controller being redundant with respect to the first CAN controller.
19. The system according to claim 18, wherein, The third CAN controller is configured as follows: Send a third control signal to the main flight module via the first CAN bus; Send a third control signal to the auxiliary flight module via the first CAN bus; and The main flight signal is received from the main flight module via the first CAN bus.
20. The system according to claim 12, wherein, The first CAN controller and the second CAN controller each include a processor configured to determine a fault state of the system and to send a control signal in response to determining the fault state.
21. A method comprising: The first controller local area network (CAN) controller sends main control signals to the main flight module and the auxiliary flight module; In response to receiving the main control signal from the first CAN controller, the main flight module performs flight-related functions instead of the auxiliary flight module; The second CAN controller sends auxiliary control signals to the auxiliary flight module and the main flight module; and In response to receiving the auxiliary control signal from the second CAN controller, the auxiliary flight module performs flight-related functions that are redundant with the flight-related functions performed by the main flight module, instead of the main flight module. in, The method further includes at least one of the following: In response to determining a fault state of the second CAN controller, the auxiliary flight module is controlled by the first CAN controller, and in response to determining a fault state of the first CAN controller, the auxiliary flight module is controlled by the second CAN controller.
22. The method of claim 21, further comprising: The first CAN controller receives flight signals from the main flight module and from the auxiliary flight module; The first CAN controller determines the additional main control signal based on the received flight signal; The second CAN controller receives flight signals from the auxiliary flight module and from the main flight module; and The second CAN controller determines additional auxiliary control signals based on the received flight signals.
23. The method according to claim 22, wherein, During normal operation, the first CAN controller determines the additional main control signal based on the flight signal received from the main flight module, but not based on the flight signal received from the auxiliary flight module, and wherein, during normal operation, the second CAN controller determines the additional auxiliary control signal based on the flight signal received from the auxiliary flight module, but not based on the flight signal received from the main flight module.
24. The method according to claim 22, wherein, The method further includes: Determine the fault status of the main flight module; and In response to determining the fault state of the primary flight module, the first CAN controller and the second CAN controller determine additional control signals based on flight signals received from the secondary flight module, rather than based on flight signals received from the primary flight module.
25. The method according to claim 21, wherein, The method further includes: A third control signal is sent from the third CAN controller to the main flight module, wherein the third control signal is redundant with the main control signal sent by the first CAN controller; Determine the fault state of the first CAN controller, wherein determining the fault state of the first CAN controller includes determining that the first CAN controller has stopped transmitting the main control signal; and In response to determining the fault state of the first CAN controller, the third CAN controller changes the third control signal, causing the main flight module to continue performing the flight mission as if the first CAN controller were still sending the main control signal.
26. The method according to claim 21, wherein, The main flight module and auxiliary flight module are contained within multiple flight-critical modules, and the method further includes: Determine the fault status of non-flight critical modules; and In response to determining the fault status of a non-flight critical module, the first CAN controller and the second CAN controller continue to send the main control signal and the auxiliary control signal, respectively.
27. The method according to claim 21, wherein, The method further includes: Determine the fault status of the first CAN bus, which is configured to send the main control signal from the first CAN controller to the main flight module; and In response to determining the fault state of the first CAN bus, the main flight module performs flight-related functions based on control signals sent by the second CAN controller via the second CAN bus.
28. A computer-readable medium comprising computer-executable instructions, which, when executed by at least one processor, cause the at least one processor to perform the method of any one of claims 1-10 and 21-27.
Citation Information
Patent Citations
Bus redundancy system of controller local area network and method and device for switching redundancy
CN102611598A
Redundancy control method of aircraft
CN106774367A