Determining gate status and corrective action using gate sensor fixtures

Abstract

The edge device receives sensor data from a sensor affixed to the movable gate. The edge device determines a position state of the movable gate based on the sensor data by inputting the received data into a machine learning model or by comparing the sensor data to values ​​associated with the position state through a calibration process. The edge device stores a log associating the position state and the sensor data. The edge device determines a health state of the movable gate using the machine learning model trained to predict the health state of the gate based on new log inputs. In response to determining that the health state of the gate is unhealthy, the edge device triggers a corrective action.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Application No. 18 / 178,477, filed March 3, 2023, which is incorporated herein by reference for all purposes.

[0002] The present disclosure relates generally to the field of machine learning, and more particularly to multi-dimensional state classification of devices. [Background technology]

[0003] Parking facilities employ gates to manage the use of their spaces and often require vehicles to pass through the gate upon one or more of entry and exit. Because many parking facilities employ fully automated, autonomous gates, they cannot rely on human recognition to ensure that the gates are operating properly at all times. In particular, with regard to parking facilities, it can be difficult to determine when a gate is damaged or in need of repair, which can lead to various problems, such as safety issues when unwanted vehicles enter or when a damaged exit gate blocks drivers from exiting the facility. Summary of the Invention [Means for solving the problem]

[0004] Disclosed herein are systems and methods for autonomously determining the status of a parking gate having a sensor and determining corrective actions. An edge device is incorporated into a parking facility that receives sensor data from a sensor affixed to the movable gate. The edge device determines the position status of the movable gate based on the sensor data by inputting the received data into a machine learning model or by comparing the sensor data to values ​​associated with the position status through a calibration process (e.g., using camera or magnet data). The edge device stores a log associating the position status and the sensor data. The edge device determines the health status of the movable gate using a machine learning model that is trained to predict the health status of the gate based on new log inputs. In response to determining that the health status of the gate is unhealthy, the edge device triggers a corrective action, such as alerting an operator or manager associated with the parking facility, transmitting a communication to the driver, or modifying a physical aspect of the parking facility, such as a status light on the gate. [Brief explanation of the drawings]

[0005] The disclosed embodiments have other advantages and features that will become more readily apparent from the detailed description, the appended claims, and the accompanying figures (or drawings), a brief introduction of which is provided below.

[0006] [Figure 1] FIG. 1 illustrates one embodiment of a system environment for determining gate status using edge devices and a parking control server.

[0007] [Figure 2] FIG. 2 illustrates one embodiment of exemplary modules operated by an edge device.

[0008] [Figure 3] FIG. 3 illustrates one embodiment of exemplary modules operated by a parking control server.

[0009] [Figure 4] FIG. 4 is a block diagram illustrating components of an exemplary machine capable of reading instructions from a machine-readable medium and executing them within a processor (or controller).

[0010] [Figure 5] FIG. 5 depicts one embodiment of an exemplary process for determining gate status and corrective actions using sensor fixtures.

[0011] [Figure 6] 6A-E illustrate an example gate in different positional states. DETAILED DESCRIPTION OF THE INVENTION

[0012] Detailed Description The figures and the following description relate to preferred embodiments by way of example only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of what is claimed.

[0013] Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures. It should be noted that, wherever practicable, like or similar reference numerals may be used in the figures and may indicate like or similar functionality. The figures depict embodiments of the disclosed system (or method) for illustrative purposes only. Those skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

[0014] (Configuration overview) FIG. 1 illustrates one embodiment of a system environment for seamless parking gate operation using edge devices and a parking control server. As depicted in FIG. 1, environment 100 includes edge device 110, camera 112, gate 114, data tunnel 116, sensor 118, network 120, and parking control server 130. While only one of each feature of the environment is depicted, this is for convenience only; any number of each feature may be present. When a singular article is used to refer to these features (e.g., "camera 112"), scenarios in which plural ones of those features are referenced are also within the scope of what is disclosed (e.g., a reference to "camera 112" may mean that multiple cameras are involved).

[0015] Edge device 110 uses camera 112 to detect vehicles approaching gate 114. In response to detecting such a vehicle, edge device 110 performs various actions (e.g., lifting the gate, updating a profile associated with the vehicle, etc.), which are described in further detail below with reference to at least FIG. 2 . Camera 112 may include any number of cameras that capture images and / or video of the vehicle from one or more angles (e.g., from behind the vehicle, from the front of the vehicle, from the side of the vehicle, etc.). Camera 112 may be in a fixed position or may be movable (e.g., along a track or line) to capture images and / or video from different angles. When the term “image” is used, this may be a standalone image or a frame of a video. When the term “video” is used, this may include multiple images (e.g., frames of a video), where multiple images may form a sequence that together form a video.

[0016] The edge device 110 also uses a gate sensor attachment to determine the health of the gate 114. Gate health is a measure of the gate's ability to function. For example, a slower-moving gate may have lower health than a faster-moving gate, or a gate that achieves a greater range of motion may have higher health than a gate with a smaller range of motion. The gate sensor attachment is a sensor, such as sensor 118, attached to the gate that collects data about the gate's function. For example, sensor 118 may be an accelerometer or a three-axis accelerometer that detects the acceleration of the gate as it opens and closes. The sensor may be attached to any type of gate.

[0017] A gate 114 may be any object that blocks entry and / or exit to a facility (e.g., a parking facility) until it is moved. For example, a gate 114 may be a pole that stands parallel to the ground to block entry or exit and then rises perpendicular to the ground to allow vehicles to pass. As another example, a gate 114 may be a pole or poles that block vehicle access until it is lowered to a position that is flush with the ground. Any form of blocking vehicle entry / exit is movable to remove the blockage and is within the context of a gate 114. In some embodiments, there is no physical gate that blocks traffic from entering or exiting the facility. Rather, in such embodiments, a gate 114 as referred to herein is a logical boundary between the inside and outside of the facility, and all embodiments disclosed herein that refer to moving a gate equally refer to a scenario in which the gate is not moved but other processing occurs when an entry and exit coincide (e.g., recording that a vehicle has left the facility). Furthermore, gate 114 may be any general gate that does not communicate directly with edge device 110. Edge device 110 may instead communicate directly with a component separate from the gate but disposed in association with the gate, which component, by its disposition, is configured to move the gate.

[0018] The edge device 110 optionally communicates information associated with the detected vehicle to the parking control server 130 over the network 120 using a data tunnel 116. The data tunnel 116 may be any tunneling mechanism, such as a virtual private network (VPN). The network 120 may be any mode of communication, including cell tower communication, internet communication, WiFi, WLAN, etc. The provided information may include an image of the detected vehicle. Additionally or alternatively, the provided information may include information extracted from or otherwise obtained based on the image of the detected vehicle (e.g., as described further below with respect to FIG. 2). Transmitting the extracted information rather than the underlying image may result in bandwidth throughput efficiencies that enable real-time or near-real-time movement of the gate 114 by avoiding the need to transmit high-data-volume images.

[0019] Parking control server 130 receives information from edge device 110 and performs actions based on that receipt. Actions may include storing information, updating profiles, retrieving information related to the information, and communicating additional responsive information back to edge device 110. Parking control server 130 may control aspects of the parking facility, such as status lights above a parking gate. Operation of parking control server 130 is described in further detail below with reference to at least FIG. 3.

[0020] 2 illustrates one embodiment of exemplary modules operated by an edge device. As depicted in FIG. 2, edge device 110 includes an entry detection module 212, an exit detection module 214, an exit event module 216, an administrator alert module 218, a sensor data reception module 220, a location state determination module 222, a calibration module 224, a health state determination module 226, a corrective action module 230, and a log data storage module 232. The modules depicted with respect to edge device 110 are merely exemplary, and fewer or additional modules may be used to accomplish the activities disclosed herein. Furthermore, while the modules of edge device 110 typically reside within edge device 110, in various embodiments, they may instead reside partially or entirely within parking control server 130 (e.g., images, rather than data from the images, are transmitted to parking control server 130 for processing). In some embodiments, the modules and functionality of the edge device 110 may be implemented in whole or in part within the sensor 118.

[0021] In one embodiment, the intrusion detection module 212 captures a series of images over time. The images are received from the camera 112. The camera 112 may continuously capture images or may capture images when a certain condition is met (e.g., when motion is detected or any other heuristic, such as during a certain time of day). In one embodiment, the edge device 110 may continuously receive images from the camera 112 and determine whether the images include a vehicle. If so, the intrusion detection module 212 may perform processing on the images that include the vehicle and discard the other images. In one embodiment, the intrusion detection module 212 may command the camera 112 to transmit only images that include the vehicle and perform processing on those received images. The captured images are associated with a movable gate or logical boundary (e.g., gate 114) in that each camera 112 faces either the gate or an area near the gate (e.g., only the entrance side, only the exit side, or both). Each image may have a timestamp and / or a sequence number. The ingress detection module 212 may associate all images containing the movement of a given vehicle from the time the vehicle enters the image to the time the vehicle exits the image (e.g., between the time the vehicle approaches a gate and then passes through the gate).

[0022] The ingress detection module 212 may determine a first dataset from a subset of images of a series of images featuring the vehicle for a vehicle approaching the ingress side. The first dataset may include a plurality of parameters describing attributes of the vehicle and a vehicle identifier of the vehicle. In one embodiment, a single machine learning model is used to produce the entire first dataset. In another embodiment, a first machine learning model is used to determine the plurality of parameters, and a different second machine learning model is used to determine the vehicle identifier.

[0023] As used herein, the term "plurality of the parameters of the vehicle" may refer to a set of data that includes both identifying attributes of the vehicle and directional attributes of the vehicle. The term "identifying attribute of the vehicle" may include any information derivable from an image that describes the vehicle, such as the vehicle's make, model, color, type (e.g., sedan vs. sport utility vehicle), height, length, bumper style, number of windows, door handle type, and any other descriptive characteristics. The term "direction attribute of the vehicle" may refer to an absolute direction (e.g., heading) or a relative direction (e.g., the direction of the vehicle relative to an entry gate and / or relative to the assigned direction of the lane that the entry gate blocks (e.g., if different gates are used for entry and exit lanes, and if a vehicle is approaching the gate from an entrance to a parking facility through an exit lane, the direction would be shown as being opposite the intended direction of the lane)). A "direction attribute of the vehicle" may also be determined relative to the camera's imaging access, thus indicating whether the vehicle is moving towards or away from the camera. The term "subset of images" refers to a set of images that include the vehicle and excludes other images that do not include the vehicle.

[0024] In a two-model approach, the intrusion detection module 212 inputs a subset of images into a first machine learning model and receives multiple parameters as output from the first machine learning model, including vehicle identification attributes and vehicle direction. In some embodiments, the output of the first machine learning model may be more granular and may include the number of objects in the image (e.g., the number of vehicles), the type of objects in the image (e.g., vehicle type information or vehicle-specific identification attribute information), a result score (e.g., confidence in each object classification), and a bounding box (e.g., of a subsegment of the image for downstream processing, such as license plates for use by the second machine learning model). The first machine learning model may be trained to output vehicle identification attributes using example data having images of vehicles labeled with one or more candidate identification attributes. For example, various images from a camera facing the gate may be manually labeled by a user to indicate the above-mentioned attributes, such as vehicle make, model, color, and type, for each image. The first machine learning model may be a supervised model trained using example data to predict these attributes for new images.

[0025] The first machine learning model may be trained to use example data to output directional attributes of the vehicle and / or output data from which the ingress detection module 212 may determine some or all of the directional attributes. The example data may show the vehicle's movement relative to one or more gates over a series of sequential frames, may be annotated with lane type (e.g., ingress lane vs. egress lane) and / or gate type (e.g., egress gate vs. ingress gate), and may be labeled with the direction between two or more frames (e.g., toward the ingress gate, away from the ingress gate, toward the egress gate, away from the egress gate). The lane type may be derived by environmental factors (e.g., the model may be trained through sufficient example data to recognize that the direction beyond a gate showing blue sky is the egress direction and the direction toward halogen lights is the ingress direction). From this training, the first machine learning model may output a direction based directly on the learned movement relative to the gate type and / or lane type, or may output a lane type and / or gate type and indicia of directional movement, from which the ingress detection module 212 may apply heuristics to determine a directional attribute (e.g., towards an entry gate, away from an entry gate, towards an exit gate, away from an exit gate). That is, a directional vector may be output along with the gate type and / or lane type (e.g., environmental factors, which may include other information such as lighting, sky information, etc., may be output along with the directional vector), and the directional vector along with the environmental factors may be used to determine the directional attribute.

[0026] Because vehicles are tracked while moving, it is advantageous to determine direction in conjunction with identifying the vehicle, since identifying both direction and the vehicle itself in one step would result in false positives. This allows separate models to be used for vehicle detection and direction detection, thus resulting in a three-model approach (two models are used for what is referred to above as the "first machine learning model," and each of these separate models is trained separately using separate training data for each separate task).

[0027] Continuing with the two-model approach, the intrusion detection module 212 may determine the vehicle identifier of a vehicle by inputting a subset of images featuring a depiction of the vehicle's license plate into a second machine learning model. That is, rather than using optical character recognition (OCR), a machine learning model may be used to decode the vehicle's license plate into a vehicle identifier. Due to the complexity of license plates, which often use different fonts (e.g., cursive vs. handwritten) against complex picture-filled backgrounds, different colors, and lighting conditions, OCR methods are often inaccurate for license plate detection. Furthermore, various license plate types are difficult to read accurately because they often contain slogans that are not generalizable. Insufficient accuracy in OCR reading may result in an inability to effectively identify the vehicle if a single character or geographic identifier determination is incorrect.

[0028] To this end, a second machine learning model can be trained to identify both the geographic nomenclature and character string of vehicle identifiers using training example images of license plates, each of which is labeled with its corresponding geographic nomenclature and character string. As used herein, the term "geographical nomenclature" can refer to a manner of identifying the jurisdiction that issued the license plate. That is, in the United States, individual states issue license plates, and the geographic identifier would identify the state. Some jurisdictions issue nationwide license plates, in which case the geographic identifier is a national identifier. The geographic identifier can identify more than one jurisdiction (e.g., in the European Union (EU), some license plates identify both the EU and the member state that issued the license plate, and the geographic identifier can identify both of those locations or only the member state). The term "string of characters" can refer to a unique symbol issued by a jurisdiction to uniquely identify a vehicle, such as a "license plate number" (which can include numbers, letters, and symbols). That is, for a given jurisdiction, the string is unique relative to other strings issued by that given jurisdiction.

[0029] Training examples of license plate images are used to train a second machine learning model, where the training examples are labeled. In one embodiment, the training examples are labeled with both geographic jurisdiction and the characters depicted in the image. The characters can be labeled individually (e.g., by labeling segments of the image containing the segments), or the entire image can be labeled with each character present or a combination thereof. In one embodiment, the training examples can be labeled with only geographic jurisdiction, and the second machine learning model predicts the geographic jurisdiction for a new image of the license plate. Following this prediction, a third machine learning model can be selected from multiple candidate machine learning models, each corresponding to a different geographic jurisdiction and trained to predict characters of a string from training examples specific to that individual geographic jurisdiction, and the selected third machine learning model can be selected based on the predicted geographic jurisdiction. The third machine learning model can be applied to images or segments thereof containing each character, thereby producing predictions from training examples specific to that jurisdiction.

[0030] In either case, the training examples may demonstrate examples in any number of conditions, such as low light conditions, dirty license plate conditions where the characters are partially or completely occluded, license plate frame conditions where the geographic identifier (e.g., the word "New York") is partially or completely occluded, conditions where the license plate cover makes the characters difficult to read directly, etc. Advantageously, by using machine learning to predict the geographic nomenclature and character strings, accuracy is improved compared to OCR because the second machine learning model is able to accurately predict the content of the license plate even when partial occlusion occurs or when lighting conditions make the characters difficult to read.

[0031] The trained second machine learning model may output the geographic nomenclature and character string (e.g., either directly or with a confidence score that exceeds a threshold applied by the intrusion detection module 212). Once all information of the dataset (e.g., multiple parameters and vehicle identifier) ​​has been determined, the edge device 110 may store, or cause to be stored, a data structure regarding the dataset in association with one or more timestamps with the subset of images. In one embodiment, the data structure is stored at the edge device 110. In one embodiment, the data structure is stored at the parking control server 130. The data structure may include additional information, such as image timestamps and / or sequence numbers of images featuring individual vehicles.

[0032] In a one-model approach, the manner in which the first and second machine learning models are trained would be applied to a single model rather than differentiating between what is learned between the two models. This would have the advantage of providing all inputs to the models as one dataset, but could also have the disadvantage of a less specialized model having noisier outputs. Furthermore, training one large model to perform all of this functionality would require intensive data and time. A large model would be slower and have lower output quality than using two separate models. The two-model approach also allows for "fail fast" processing to occur, i.e., detecting vehicles and taking action based on that detection even before other activities (e.g., license plate reading) are completed.

[0033] Regardless of the model approach used, in some embodiments, the ingress detection module 212 may determine from the vehicle's directional attributes whether the directional attributes are consistent with an ingress movement. That is, if the ingress detection module 212 determines that the vehicle is approaching a gate (e.g., in an ingress lane) with directional attributes consistent with the gate's function (e.g., using the ingress lane rather than the egress lane), the ingress detection module 212 may determine that an ingress movement is occurring. In response to detecting that an ingress movement is occurring, the ingress detection module 212 may move the gate to allow entry into the facility blocked by the gate (or, if the gate is a logical boundary, record the vehicle as entering the facility without the need to move the gate). Also, in response to detecting that an ingress movement is occurring, the ingress detection module 212 may store a data structure in a database in an entry corresponding to the vehicle. For example, this may be stored in the ingress data database 358, discussed in more detail below, for use in matching exiting movements by the same vehicle to ingress movements. In one embodiment, further in response to detecting that an entry movement is occurring, a data structure may also be stored in profile database 356 referencing the vehicle or the user of the vehicle to record the vehicle's historical activity when entering the facility.

[0034] The exit detection module 214 operates in a manner similar to the entry detection module 212 in that machine learning is applied in the same manner, except for detecting exit events. That is, the same data set collected when a vehicle performs an entry movement is executed for an exit movement when a vehicle is detected approaching a gate 114 to exit the facility. When an exit movement is detected (e.g., if the vehicle is determined to have directional attributes consistent with approaching a gate designated for use as an exit), the exit detection module 214 determines that an exit event may occur (e.g., other activities such as generating and storing data structures as described with respect to entry events may also be performed).

[0035] The exit event module 216 compares information in the dataset acquired by the exit detection module 214 with information stored in the entry event data structure to determine whether a match exists. The exit event module 216 determines a match where a heuristic is satisfied; such a data structure indicates that a vehicle with the same geographic nomenclature has entered the facility. Even using the second machine learning model described, license plate readings are not perfect, so the exit event module 216 may not find a match based solely on the geographic nomenclature. To this end, a match may be determined based on a partial match of the geographic nomenclature and / or other identifying information, such as identifying other matching vehicle attributes, such as make, model, color, etc. Any heuristic may be programmed to determine whether a match occurs. In response to detecting a match, the exit event module 216 may instruct the data structure to be updated to indicate that the vehicle has exited the facility and / or (e.g., if the gate 114 is a physical gate rather than a logical boundary) may raise the gate 114, thus allowing the vehicle to exit the facility.

[0036] In response to determining that a match does not exist, the administrator alert module 218 may alert an administrator, who may manually determine whether a match exists and / or communicate with the driver of the vehicle to take corrective action. In embodiments where a match does not exist, the administrator alert module 218 may determine that the vehicle identifier is unknown. In response to determining that the vehicle identifier is unknown, the administrator alert module 218 may transmit an alert to the administrator, the alert being associated with at least a portion of the subset of images. That is, the alert may point to one or more images or portions that include identifying information (e.g., a license plate, a distinguishing feature such as a bumper sticker, etc.). The administrator alert module 218 may receive input from the administrator defining the vehicle identifier and may use the input to find matching entry data. In some embodiments, the administrator alert module 218 may alert the administrator as part of a corrective action (see corrective action module 230 for further details).

[0037] The sensor data receiving module 220 receives sensor data from the sensor 118 affixed to the movable gate 114. The sensor data is data recorded by the sensor that provides information about the gate's function. For example, if the sensor is a three-axis accelerometer, the sensor data may include time-correlated acceleration data that provides information about the gate's movement. In some embodiments, the sensor 118 may contain a magnetically operated switch (e.g., a magnetic reed switch) that changes state when in proximity to a magnet, thereby providing information about the gate's movement. The sensor data receiving module 220 may receive the sensor data by communicating with the sensor 118 using a communication protocol, such as a Bluetooth® or Bluetooth® Low Energy (BLE) protocol. In some embodiments, the sensor data receiving module 220 may receive the sensor data at consistent or aperiodic time intervals. In some embodiments, the sensor data receiving module 220 may begin receiving sensor data from the sensor 118 in response to the sensor detecting gate movement. For example, the sensor data receiving module 220 may begin receiving data in response to detecting a change in acceleration above a threshold or an acceleration value that differs from the acceleration value of the gate's closed position. The sensor data receiving module 220 may stop receiving sensor data from the sensor 118 in response to detecting an absence of movement for a time period that exceeds a threshold after starting to receive data, or in response to exceeding a threshold time period. By receiving data in response to gate movement, the sensor data receiving module 220 optimizes power usage of the edge device 110 for sensor data transmission. The sensor data receiving module 220 may store the received data or process it as it is received (e.g., as part of a data stream).

[0038] The position state determination module 222 determines the position state of the movable gate. The position state may describe the position of the movable gate, such as whether the gate is in an open position, a closed position, or other. The open position state refers to the state of the gate that allows vehicles to pass through to either enter or exit the parking facility. For some gates, such as a bar that swings or rises to open, the open state may be similar to an "up" state. However, for different gates, such as a pole or poles that lower into the ground to open, the open state may be similar to a "down" state. The closed position state may similarly refer to a down or up state depending on the gate type. For gates that move horizontally, the open and closed states may be associated with the left or right positions of the gate. The "other" position state refers to when the gate is not in either the open or closed position. One example of the other position state may be when the gate is between the open and closed states as part of an opening or closing process. Another example of an other position state may be when the gate exceeds the boundaries of what the position state determination module 222 considers open or closed, such as when the gate is too open. For some gates, such as bar gates, the position state may describe the lateral position of the movable gate, such as whether the gate is stationary in a normal position (i.e., not moved laterally) or in a semi-open position (i.e., moved laterally, for example, after a vehicle collision). The position state may be a discrete state (e.g., open or closed) or a continuous state (e.g., 45 degrees open, 45.1 degrees open, etc.), where the granularity of the continuous state depends on the resolution of the sensor. Examples of open, closed, other, normal, and semi-open states are shown in FIG. 6.

[0039] The position state determination module 222 determines the position state of the gate based on the received sensor data. For example, in response to the sensor data indicating an acceleration value near zero, the position state determination module 222 may determine that the gate is in a closed state, i.e., a resting position for the gate. In another example, in the case of a bar gate, in response to the sensor data indicating a positive acceleration value exceeding a threshold acceleration value, the position state determination module 222 may determine that the gate is moving from a closed state to an open state. In response to the sensor data indicating a negative acceleration value exceeding a threshold acceleration value followed by a default acceleration value (e.g., acceleration due to gravity), the position state determination module 222 may determine that the gate is moving from the open state back to the closed state.

[0040] In some embodiments, the position state determination module 222 may determine the position state of the gate using a sensor containing a magnetically operated switch (e.g., sensor 118) and a magnet or multiple magnets. The magnet and sensor 118 may be positioned to provide information about the gate's position. For example, for a gate that is a pole that moves up from the ground and down into the ground, the sensor 118 may be positioned on the pole and the magnet may be positioned on the ground next to the pole. In this example, when the pole is in the open position (down into the ground), the magnetically operated switch on the sensor 118 is close to the magnet. The sensor 118 may detect a current indicating that the gate is open, and the position state determination module 222 may determine that the gate's position information is open. Similarly, when the pole is in the closed position (up from the ground), the magnetically operated switch on the sensor 118 is far from the magnet. The sensor 118 may detect a smaller (or zero) current indicating that the gate is closed. The position state determination module 222 may determine that the position state of the gate is closed. However, in some embodiments, using a sensor containing a magnetically operated switch and a magnet for position state determination may allow the position state determination module 222 to sense only two states: open and closed.

[0041] In some embodiments, the position state determination module 222 may use the camera 112 in addition to a machine learning model to determine the position state of the gate without using the sensor 118. The position state determination module 222 may train a machine learning model to receive camera data and output the position state of the gate. The training data may include historical camera data from similar or identical gates that has been labeled using location information determined by a calibration process or another labeling method, such as manual labeling or computer vision. However, in some embodiments, the position state determination module 222 may limit access to the camera data, for example, when the camera is not facing the gate or when the camera is damaged. In this case, the position determination module 222 may rely primarily on sensor data, such as acceleration data, through the use of a calibration process or a machine learning model. Furthermore, by relying on sensor data instead of directly relying on camera data, the position state determination module 222 may use less processing power to determine the state and may avoid challenges associated with an obstructed field of view from the camera.

[0042] The position state determination module 222 may process the sensor data. Processing the sensor data may include filtering or smoothing the sensor data (e.g., using a moving average filter). The position state determination module 222 may perform a transform on the sensor data, such as a fast Fourier transform (FFT), so that the position state determination module 222 may analyze the sensor data in the frequency domain instead of the time domain. The position state determination module 222 may use any signal processing or data filtering technique. If the sensor is an accelerometer, the position state determination module 222 may adjust the accelerometer values ​​to account for acceleration caused by gravity.

[0043] In some embodiments, the position state determination module 222 may determine the position state by comparing the sensor data with stored values ​​associated with the position state through a calibration process. The calibration process may be performed by the calibration module 224. In some embodiments, the calibration module 224 may store accelerometer values ​​corresponding to a closed position state and accelerometer values ​​corresponding to an open position state. In some embodiments, the calibration module 224 may determine the position state to be closed in response to determining that the acceleration of the gate is within an acceptable range of the stored accelerometer values ​​corresponding to the closed position state. The calibration module 224 may determine the position state to be open in response to determining that the acceleration of the gate is within an acceptable range of the stored accelerometer values ​​corresponding to the open position state. The calibration module 224 may determine the position state to be other in response to determining that the acceleration of the gate is not within an acceptable range of the stored accelerometer values ​​for either the open or closed state. In some embodiments where the sensor is a three-axis accelerometer, as part of the calibration process, the calibration module 224 may store a threshold acceleration value along an axis perpendicular to the gate and parallel to the ground plane of the parking facility, store an indication that acceleration values ​​below the threshold acceleration value correspond to a normal position state, and store an indication that acceleration values ​​above the threshold acceleration value correspond to a half-open position state. In some embodiments, the position state determination module 222 may determine that the gate is in more than one state at a time. For example, the gate can be in a closed state and a normal state at the same time, or a closed state and a half-open state at the same time.

[0044] In some embodiments, calibration module 224 may use data from a sensor containing a magnetically operated switch (e.g., sensor 118) and a magnet or magnets. The magnet and sensor 118 may be positioned to provide information about the position of the gate. In response to sensor 118 indicating that the gate is open, calibration module 224 may pair acceleration values ​​received during the magnet data indicating that the gate is open with an open position state. Similarly, in response to magnet data indicating that the gate is closed, calibration module 224 may pair accelerometer values ​​received during the magnet data indicating that the gate is closed with a closed position state. An example of a magnet attachment on a bar gate is shown in FIG. 6.

[0045] In some embodiments, calibration module 224 may use data from a camera, such as camera 112. In response to the camera data indicating that the gate is closed, calibration module 224 may pair accelerometer values ​​received during the camera data indicating that the gate is closed with a closed position state. Similarly, in response to the camera data indicating that the gate is open, calibration module 224 may pair accelerometer values ​​received during the camera data indicating that the gate is open with an open position state.

[0046] In some embodiments, the location state determination module 222 may determine the location state by using a supervised machine learning model trained to receive sensor data and output the location state of the gate. The training data may include historical sensor data from similar or identical gates that has been labeled using location information determined by a calibration process or by another labeling method, such as computer vision. If the location state determination module training data is labeled using computer vision, the location state determination module 222 may train the machine learning model using acceleration data from the sensors that can be correlated with the computer vision determination of the state based on timestamps in both data sets.

[0047] The location state determination module 222 may store a log (e.g., in the log data storage 232) associating sensor data with determined location states. The log may include sensor data, such as accelerometer values, a timestamp associated with the sensor data, and a determined state associated with the sensor data. In some embodiments, the log data storage 232 is a cloud-based storage system.

[0048] The health status determination module 226 determines the health status from one or more stored logs associated with the gate. The health status determination module 226 may determine the health status as healthy or unhealthy. A healthy status indicates that the gate is performing as expected. For example, a gate performing as expected may move between an open state and a closed state with an acceptable speed, with sustained movement, or only in response to a command to move (e.g., a button press). An unhealthy status indicates that the gate is performing outside of expected performance and may require maintenance. In some embodiments, the health status determination module 226 may determine the health status as one of a set of healthy or unhealthy states. The set of unhealthy states may include remaining in a position state, such as a half-open position state, or other position state for a time period that exceeds a threshold time period. The set of unhealthy states may include states describing gate behavior, such as opening too slowly, opening too quickly, moving unsteadily, wobbling, or crashing. An "opening too slowly" health state may refer to a gate state in which the average acceleration of the gate decreases below a threshold acceleration value over a given time window. Similarly, an "opening too quickly" health state may refer to a gate state in which the average acceleration of the gate increases above a threshold acceleration value over a given time window. A "moving inconsistently" health state may refer to a gate state in which the gate moves from a closed position to an open position (or vice versa) but does not move with smooth motion or a constant velocity. A "wobbling" health state may refer to a gate state in which the gate exhibits repeated movement up and down (perpendicular to the ground), left and right (parallel to the ground), or some combination of the two directions. A wobbling health state may not always be an unhealthy state. The health state determination module 226 may determine that the health state is perturbed and unhealthy if the amount of perturbation exceeds a threshold.The health status determination module 226 may measure the amount of perturbation as the amount of gate displacement between each movement or the amount of time that elapses before the gate settles into a rest position. In some embodiments, in response to the amount of gate displacement during the perturbation exceeding a threshold, the health status determination module 226 may determine the health status of the gate to be "crashed through."

[0049] The health state determination module 226 may determine a health state by observing changes in sensor data or position state within a time window. For example, in response to determining that the average acceleration of a gate is decreasing below a threshold acceleration value within a time window (e.g., due to the life of a motor controlling the gate's movement), the health state determination module 226 may determine that the gate is opening too late and that the health state is unhealthy. Or, in response to determining that the gate is in some other position state for a percentage of the time window exceeding a threshold percentage, the health state determination module 226 may determine that the health state is unhealthy. Similarly, in response to determining that the gate's position state is half-open at any point within the time window, the health state determination module 226 may determine that the health state is unhealthy. In some embodiments, the health state determination module 226 may determine a health state for a cloud computing environment.

[0050] In some embodiments, the health status determination module 226 may determine the health status using a machine learning model. The machine learning model may be a supervised model trained using existing logs to predict the health status of a gate for new logs. The existing logs may include sensor data, location status, and time data. The logs may be annotated with gate attributes such as location and type (e.g., exit gate, entry gate). The logs may be labeled with the health status (e.g., opening too slowly, opening too quickly, moving unsteadily, shaking, crashing, remaining partially open, or in other location states for an excessively long period of time) or with the level of urgency associated with the gate's condition (e.g., emergency may apply to a crash gate, and non-emergency may apply to a gate that opens too slowly).

[0051] In some embodiments, the health status determination module 226 may classify the status of a gate at a less granular level, for example, classifying the status as either healthy or unhealthy, or training a machine learning model to classify the status as healthy, unhealthy / non-urgent, or unhealthy / urgent.

[0052] In some embodiments, the machine learning model may be a general classifier that maps location states directly to health states (e.g., a location state of a crash maps to unhealthy) or that maps normalized sensor data to health states. In some embodiments, the machine learning model is specific to a gate type. A first model trained to determine gate type using data from the camera 112 may determine the gate type of the gate and then feed one or more entries to a second machine learning model corresponding to the gate type. The health state determination module 226 may determine the health state by inputting one or more logs into the machine learning model and receiving the health state as an output from the model.

[0053] Corrective action module 230 triggers a corrective action in response to health status determination module 226 determining that the health status is unhealthy. In one embodiment, the corrective action is an alert transmitted to an operator or administrator (e.g., using administrator alert module 218). The alert can be any form of communication that informs the operator of the gate's health status. Examples of an alert can be an automated message sent as a phone call, a text, or a push notification to the operator's mobile device, an email message sent to the operator's email address, an alert in the vicinity of the gate such as a message broadcast through a speaker, or a visual alert such as a light on the gate itself. Corrective action module 230 can determine who to alert or prompt regarding repairs and the level of urgency to communicate based on information about the gate (e.g., gate location, health status, or health status of gates in the same parking facility) or other heuristics (e.g., time of day, operator work schedule). For example, in response to determining that the health status is a collision, the edge device 110 may contact the parking facility operator and communicate a high urgency. In a similar example, in response to determining that the health status is unhealthy and that a gate is blocking the main entrance / exit to the parking facility during peak hours, the edge device 110 may contact the parking facility operator and communicate a high urgency. In an alternative example, in response to determining that the health status is unhealthy but that an additional gate with a healthy health status exists that provides the same functionality as the gate with the unhealthy health status, the corrective action module 230 may contact the parking facility operator and communicate a low urgency.

[0054] In some embodiments, the corrective action includes modifying a physical aspect of the parking facility. For example, the corrective action module 230 may send a notification to the parking control server 130 to change a status light above a parking gate to indicate that the gate is closed. In some embodiments, the corrective action includes transmitting a communication (e.g., via a mobile application, SMS, or push notification) to a driver (e.g., a driver in or near the parking facility) to use a different gate.

[0055] In one embodiment, edge device 110 applies computer vision to determine environmental factors surrounding a vehicle. As used herein, the term "environmental factor" may refer to features that affect traffic flow near gate 114, such as roadway traffic blocking an exit from a facility, the orientation of vehicles in the image relative to one another, etc. In one embodiment, when commanding a movable gate to move, edge device 110 applies parameters based on the determined environmental factors (e.g., waiting for gate 114 to open despite a match between the exit and entry because a vehicle is ahead of the exiting vehicle and therefore blocking the exit).

[0056] FIG. 3 illustrates one embodiment of exemplary modules operated by the parking control server. As depicted in FIG. 3, the parking control server 130 includes a vehicle identification module 332, a vehicle direction module 334, a parameter determination model training module 336, a license plate model training module 338, an event reading module 340, a model database 352, a profile database 356, a training example database 354, entry data 358, and exit data 360. The modules and databases depicted in FIG. 3 are merely exemplary, and fewer or more modules and / or databases may be used to accomplish the activities disclosed herein. Furthermore, the modules and databases depicted within the parking control server 130 may be distributed, in whole or in part, to the edge device 110, which may perform, in whole or in part, any of the activities described with respect to the parking control server 130. Furthermore, the modules and databases may be maintained separately from any of the entities depicted in FIG. 1 (e.g., the decision model training module 336 and the license plate training module 338 may be stored entirely offline from or in an entity separate from the parking control server 130).

[0057] The vehicle identification module 332 identifies the vehicle using the first machine learning model described with respect to the intrusion detection module 212. In particular, the vehicle identification module 332 accesses the first machine learning model from the model database 352, applies the input image and / or any other data to the machine learning model, and receives the vehicle parameters therefrom. The vehicle identification module 332 operates in scenarios where the image is transmitted to the parking control server 130 for processing rather than being processed by the edge device 110. Similarly, the vehicle direction module 334 determines the direction of the vehicle in the image captured at the edge device 110 by the camera 112 in the manner described above with respect to the intrusion detection module 212, except by using as input the image and / or other data received at the parking control server 130 rather than being processed by the edge device 110.

[0058] Parameter determination model training module 336 trains a first machine learning model to predict vehicle parameters in the manner described above with respect to intrusion detection module 212. The parameter determination model training module may additionally train the first machine learning model to predict vehicle direction. The parameter determination model training module may access training examples from training example database 354 and store the model in model database 352. Similarly, license plate model training module 338 may train a second machine learning model using training examples stored in training example database 354 and store the trained model in model database 352.

[0059] The event reading module 340 receives instructions from the exit event module 216 to read entry data from the entry data database 358 that matches the detected exit data and return at least partially matching data and / or a determination of whether a match was found to the exit event module 216. The event reading module 340 optionally stores the exit data in the exit data database 360.

[0060] A profile database 356 stores profile data about encountered vehicles. For example, identification information and / or license plate information may be used to index the profile database 356. As vehicles enter and exit the facility, the profile database 356 may be populated with a profile for each vehicle that stores those entry and exit events. The profile may indicate the owner and / or driver of the vehicle and may indicate contact information for those users. The event reading module 340 may read the contact information when an event is detected and may initiate communication with the user (e.g., a welcome message to the parking facility or other information related to how to use the facility).

[0061] FIG. 4 is a block diagram illustrating components of an exemplary machine capable of reading instructions from a machine-readable medium and executing them in a processor (or controller). FIG. 4 is a block diagram illustrating components of an exemplary machine capable of reading instructions from a machine-readable medium and executing them in a processor (or controller). Specifically, FIG. 4 shows a diagrammatic representation of a machine in the exemplary form of a computer system 400, within which program code (e.g., software) may be executed to cause the machine to perform any one or more of the methodologies discussed herein. The program code may consist of instructions 424 executable by one or more processors 402. In alternative embodiments, the machine operates as a stand-alone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in a server / client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

[0062] The machine may be a computing system capable of executing (sequentially or otherwise) instructions 424 that specify actions to be taken by the machine. Furthermore, although only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or together execute instructions 424 to perform any one or more of the methodologies discussed herein.

[0063] The exemplary computer system 400 includes one or more processors 402 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), one or more application specific integrated circuits (ASICs), one or more radio frequency integrated circuits (RFICs), a field programmable gate array (FPGA)), a main memory 404, and a static memory 406, which are configured to communicate with each other via a bus 408. The computer system 400 may further include a visual display interface 410. The visual interface may include software drivers that enable (or provide) a user interface to be rendered on a screen, either directly or indirectly. The visual interface 410 may interface with a touch-enabled screen. The computer system 400 may also include input devices 412 (e.g., keyboard, mouse), cursor control devices 414, a storage unit 416, signal generation devices 418 (e.g., microphone and / or speaker), and a network interface device 420, which are also configured to communicate via the bus 408.

[0064] The storage unit 416 includes a machine-readable medium 422 (e.g., a magnetic disk or solid-state memory) on which are stored instructions 424 (e.g., software) that embody any one or more of the methodologies or functions described herein. The instructions 424 (e.g., software) may also reside, completely or at least partially, within the main memory 404 or within the processor 402 (e.g., within the processor's cache memory) during execution.

[0065] 5 is a flowchart for a method of determining the state of a gate using a sensor attachment, according to some embodiments. Alternative embodiments may include more, fewer, or different steps than those illustrated in FIG. 5, and the steps may be performed in a different order than those illustrated in FIG. 5. In some embodiments, the method steps may be performed by a server, such as parking control server 130.

[0066] The edge device 110 receives (510) sensor data from a sensor affixed to the movable gate (e.g., using the sensor data receiving module 220). The sensor data may be data from an accelerometer (acceleration data). The edge device 110 may receive the sensor data from the sensor 118 affixed to the gate 114 via Bluetooth® communication, such as using the BLE protocol.

[0067] The edge device 110 determines (520) the position state of the movable gate based on the received sensor data (e.g., using the position state determination module 222). The edge device 110 may determine the position state by comparing the sensor data to values ​​associated with the position state through a calibration process (e.g., using the calibration module 224). The calibration process may use data from the camera 112 or a magnet. The edge device 110 may determine the position state by using a supervised machine learning model that is trained to receive the sensor data and output the position state of the gate.

[0068] The edge device 110 stores (530) a log associating the sensor data with the determined location state (eg, using the location state determination module 222 and the log data storage device 232).

[0069] The edge device 110 determines (540) the health state from one or more stored logs associated with the gate by observing changes in sensor data or location conditions within a time window or by using a machine learning model, such as a supervised model trained using existing logs to predict the health state for new logs (e.g., using the health state determination module 226). The edge device 110 determines (550) whether the health state is unhealthy (e.g., using the health state determination module 226).

[0070] In response to determining that the health state is unhealthy, the edge device 110 triggers (560) a corrective action (e.g., using the corrective action module 230), which may include alerting an operator or manager or modifying some aspect of the parking facility.

[0071] 6A-E illustrate an example gate in different positions. Each figure depicts a bar-style gate 114 blocking a path between two barriers 610. The gate 114 is fixed at one end to one of the barriers 610 and can rotate around the point at which it is attached. In some embodiments, there may only be a barrier 610 to which the gate is fixed. Attached to the gate 114 is a sensor 118. The figures show the sensor 118 attached to the end of the gate 114 near the rotation point; however, the sensor 118 may be attached anywhere on the gate 114. The sensor 118 may broadcast a signal 620 to communicate sensor data to the edge device 110 (not shown). Shown on the sensor 118 is an acceleration vector 630 pointing in the direction of acceleration due to gravity. A magnet 640 is shown attached to one side of the barriers 610 such that the sensor 118 is near the magnet 640 when the gate is in the closed position (FIG. 6A).

[0072] 6A illustrates gate 114a in a closed position. In this position, gate 114a is lowered, blocking entry or exit between barriers 610a. Acceleration vector 630a forms a 90-degree angle with gate 114a (i.e., a right angle). Magnet 640a is near sensor 118a and can generate a current.

[0073] 6B illustrates gate 114b in the open position. In this position, gate 114b is elevated so that a vehicle can pass through barrier 610b. Acceleration vector 630b forms a zero-degree angle with gate 114b (i.e., is parallel). Magnet 640b is farther from sensor 118b and may generate less current than was generated while gate 114b was in the closed position (FIG. 6A).

[0074] FIG. 6C illustrates gate 114c in an other position. In this example, gate 114c is in the other position because its position exceeds the boundary of what position state determination module 222 considers to be open. That is, gate 114c has rotated too far past the open position. In another example, gate 114c may be in the other position when gate 114c is between the open and closed positions or when gate 114c has rotated too far past the closed position. Acceleration vector 630c forms an acute angle with gate 114c. Magnet 640c is farther from sensor 118c and may generate less current than was generated while gate 114c was in the closed position (FIG. 6A).

[0075] Figure 6D is shown from a perspective looking down on the gate from above while the gate is in the closed position. Figure 6D illustrates gate 114d in its normal lateral position. The angle of gate 114d is parallel to horizontal centerline 612d of barrier 610d. Acceleration vector 630d is shown as an "x" indicating its direction into the page. Because gate 114d is in the closed position, acceleration vector 630d forms a 90-degree angle with horizontal centerline 612d. Because gate 114d is in the closed position, magnet 640d is near sensor 118d and may generate a magnetic force.

[0076] Figure 6E is shown from a perspective looking down on the gate from above while the gate is in the closed position. Figure 6E illustrates gate 114e in a semi-open lateral position. Gate 114e forms an angle with horizontal centerline 612e of barrier 610e. Acceleration vector 630e is shown as an "x" indicating its direction into the page. Because gate 114e is in the closed position, acceleration vector 630e forms a 90-degree angle with horizontal centerline 612e. Although gate 114e is in the closed position, because the gate's lateral position is semi-open, magnet 640e is no longer near sensor 118e and may generate less current than it generated while gate 114e was closed and in its normal position.

[0077] Additional Configuration Considerations

[0078] Throughout this specification, multiple instances may implement components, operations, or structures described as a single instance. While individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed in parallel, and nothing requires the operations to be performed in the order shown. Structures and functions presented as separate components in example configurations may be implemented as combined structures or components. Similarly, structures and functions presented as single components may be implemented as separate components. These and other variations, modifications, additions, and improvements are within the scope of the subject matter of this specification.

[0079] Certain embodiments are described herein as including logic or several components, modules, or mechanisms. The modules may constitute either software modules (e.g., code embodied on a machine-readable medium and processor-executable code) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In exemplary embodiments, one or more computer systems (e.g., stand-alone, client, or server computer systems) or one or more hardware modules (e.g., processors or groups of processors) of a computer system may be configured by software (e.g., applications or application portions) as hardware modules that operate to perform certain operations as described herein.

[0080] In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module is a tangible component that may comprise dedicated circuitry or logic that is permanently configured (e.g., as a specialized processor such as a field programmable gate array (FPGA) or application specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry that is temporarily configured by software (e.g., as contained within a general-purpose processor or other programmable processor) to perform certain operations. It should be understood that the decision to mechanically implement a hardware module in dedicated and permanently configured circuitry or temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0081] The implementation of some of the operations may be distributed among one or more processors and spread across several machines rather than just residing within a single machine. In some exemplary embodiments, one or more processors or processor-implemented modules may be located within a single geographic location (e.g., a home environment, an office environment, or a server farm). In other exemplary embodiments, one or more processors or processor-implemented modules may be distributed across several geographic locations.

[0082] Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored within a machine memory (e.g., a computer memory) as bits or binary digital signals. These algorithms or symbolic representations are examples of techniques used by those skilled in the data processing arts to convey the significance of their work to others skilled in the art. As used herein, an "algorithm" is a self-consistent sequence of operations or similar processes leading to a desired result. In this context, algorithms and operations involve physical manipulations of physical quantities. Usually, though not necessarily, such quantities take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as "data," "content," "bit," "value," "element," "symbol," "character," "term," "number," "numeral," or the like. However, these terms are merely convenient labels and are intended to be associated with appropriate physical quantities.

[0083] Unless specifically stated otherwise, discussions herein using words such as "processing," "computing," "calculating," "determining," "presenting," "displaying," or the like may refer to the actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities in one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0084] Upon perusal of this disclosure, those skilled in the art will appreciate still additional alternative structural and functional designs for systems and processes for seamless entry and exit to a parking facility blocked by a movable gate through the principles disclosed herein. Thus, while specific embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the precise arrangement and components disclosed herein. It will be apparent to those skilled in the art that various modifications, changes, and variations can be made in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope as defined in the appended claims.

Claims

1. 1. A method, comprising: receiving, at an edge device within a threshold proximity range of a parking facility, sensor data from a sensor fixed to a movable gate forming a barrier for vehicles to said parking facility; determining a position state of the movable gate based on the sensor data by the edge device; storing, by the edge device, a log associating the location state and the sensor data; determining a health state of the gate from one or more logs including the log, the health state indicating the health of the gate; determining whether the health condition is unhealthy; triggering a corrective action in response to determining that the health state is unhealthy; and A method comprising:

2. The method of claim 1 , wherein the sensor data is received in response to movement of the movable gate.

3. The method of claim 1 , further comprising calibrating the edge device to transform given sensor data into a candidate location state of a plurality of candidate location states.

4. the sensor is an accelerometer, and calibrating the edge device comprises: storing, at the edge device, a first accelerometer value corresponding to a closure position state; storing, in the edge device, a second accelerometer value corresponding to an open position state; The method of claim 3, comprising:

5. The method of claim 4 , wherein a tolerance range is defined for the first accelerometer value, within which a position state of the closure is determined and outside of which an unknown position state is determined.

6. The accelerometer is a three-axis accelerometer, and calibrating the edge device further comprises: storing in the edge device a threshold force value along an axis perpendicular to the gate and parallel to the plane of the ground of the parking facility; storing, at the edge device, an indication that a force value below the threshold force value corresponds to a positional state of perturbation; storing, at the edge device, an indication that a force value exceeding the threshold force value corresponds to a positional state of impact; The method of claim 4, comprising:

7. determining said position state using camera data; pairing the determined position state with accelerometer values ​​received while the camera data indicated that the gate was in the determined position state; The method of claim 4 further comprising:

8. determining said position state using magnet data; pairing the determined position state with accelerometer values ​​received while the magnet data indicated that the gate was in the determined position state; The method of claim 4 further comprising:

9. Determining the health state includes: inputting the one or more logs into a supervised machine learning model; receiving the health state as an output from the supervised machine learning model; The method of claim 1 , comprising:

10. 10. The method of claim 9, wherein the supervised machine learning model is trained using existing logs including sensor data, location states, and time data, annotated with gate attributes, and labeled with a health state, and the health state is determined by comparing the accelerometer value of the gate within a time window to a threshold value.

11. The method of claim 9 , wherein the machine learning model is trained to output a health state for a particular gate type.

12. Determining the health state includes: inputting the normalized sensor data into a classifier; receiving the health state as an output from the classifier; The method of claim 1 , comprising:

13. Determining the position state includes: inputting the one or more logs into a supervised machine learning model; receiving the location state as an output from the supervised machine learning model; The method of claim 1 , comprising:

14. 14. The method of claim 13, wherein the supervised machine learning model is trained using historical sensor data from the movable gate and labeled with position states, the position states being determined by a calibration process.

15. The method of claim 1 , wherein the corrective action comprises an alert prompt to an engineer regarding immediate restoration in response to determining that the health status of the gate is a collision.

16. 1. A non-transitory computer-readable medium including a memory having instructions encoded thereon, the instructions, when executed by one or more processors, causing the one or more processors to perform operations, the instructions comprising: receiving, at an edge device within a threshold proximity range of a parking facility, sensor data from a sensor fixed to a movable gate forming a barrier for vehicles to said parking facility; determining a position state of the movable gate based on the sensor data by the edge device; storing, by the edge device, a log associating the location state and the sensor data; determining a health state of the gate from one or more logs including the log, the health state indicating the health of the gate; determining whether the health condition is unhealthy; triggering a corrective action in response to determining that the health state is unhealthy; and A non-transitory computer-readable medium comprising instructions for performing

17. 17. The non-transitory computer readable medium of claim 16, wherein the sensor data is received in response to movement of the movable gate.

18. 20. The non-transitory computer-readable medium of claim 16, wherein the instructions further comprise instructions for calibrating the edge device to transform given sensor data to a candidate location state of a plurality of candidate location states.

19. The sensor is an accelerometer, and the instructions to calibrate the edge device include: storing, at the edge device, a first accelerometer value corresponding to a closure position state; storing, in the edge device, a second accelerometer value corresponding to an open positional state; 20. The non-transitory computer-readable medium of claim 16 comprising instructions for:

20. 1. A system comprising: a memory having instructions encoded thereon; one or more processors, wherein the one or more processors, when executing the instructions, receiving, at an edge device within a threshold proximity range of a parking facility, sensor data from a sensor fixed to a movable gate forming a barrier for vehicles to said parking facility; determining a position state of the movable gate based on the sensor data by the edge device; storing, by the edge device, a log associating the location state and the sensor data; determining a health state of the gate from one or more logs including the log, the health state indicating the health of the gate; determining whether the health condition is unhealthy; triggering a corrective action in response to determining that the health state is unhealthy; and one or more processors configured to perform operations including A system comprising:

Images