Variable Frequency Drive control using Machine Learning

M. Khubaib Shahzad (2020320) Hamza Zahid (2020298)

u2020320@giki.edu.pk u2020298@giki.edu.pk

Hassan Siddique (2020307) Umar Farooq (2020500)

u2020307@giki.edu.pk u2020500@giki.edu.pk

Samiyan Baig (2020234) Anas Hamdani (2020905)

u2020234@giki.edu.pk u2020905@giki.edu.pk

Abstract—This paper presents an innovative approach to potential applications in industrial automation, robotics, and
motor driver frequency adjustment by integrating facial smart home environments.
recognition technology and machine learning. Traditional
Variable Frequency Drives (VFDs) often require manual
II. SYSTEM MODEL
adjustments, limiting dynamic control capabilities. Our system
utilizes a facial recognition model trained with deep neural
networks to accurately capture and interpret operators' facial
expressions in real-time. This approach eliminates manual
adjustments, providing an intuitive interface for efficient
motor speed control. The applications of this system extend to
industrial automation, robotics, and smart homes.

Keywords: Facial recognition, Machine learning, Variable

Frequency Drive (VFD), Motor driver control, Dynamic
control, User-friendly interface, Deep neural networks,
Industrial automation.

I. INTRODUCTION
The implementation of Variable Frequency Drives
(VFDs) has brought significant advancements to motor
control systems. In this project, we explored the concept of
controlling the motor's frequency using machine learning
algorithms, specifically by recognizing and analyzing facial
expressions. To realize this, we employed a hardware setup
consisting of an Arduino-based system generating
Sinusoidal Pulse Width Modulation (SPWM) signals and
utilized MOSFETs for switching. The AC input was
rectified and fed into an inverter, enabling us to control the
frequency using the generated SPWM signals.
The machine learning aspect involved training a facial
recognition model using deep neural networks to accurately
capture and interpret facial expressions in real-time. By
showing their faces to the system, operators could influence
the motor's frequency through the ML algorithm's analysis
of their expressions. This approach eliminated the need for
manual adjustments and provided an intuitive interface for
controlling motor speeds.
Overall, this project showcased the integration of
machine learning algorithms with hardware components to
achieve variable frequency control in motor drives. The
combination of SPWM generation with MOSFET
switching, along with the facial recognition-based machine
learning model, demonstrated an innovative approach to
motor control. The project's findings contribute to the
advancement of intelligent motor control systems and offer
Fig 2.1: System Model
 III. MACHINE LEARNING
A. What is Machine Learning?
Machine Learning (ML) is a subset of artificial
intelligence that focuses on developing algorithms and
models that enable computers to learn and make predictions
or decisions without explicit programming. In essence, ML
algorithms are designed to identify patterns and extract
meaningful insights from large datasets, enabling systems to
learn and improve over time.
In the context of motor control using machine learning,
ML algorithms are employed to analyze and interpret facial
expressions in real-time. These algorithms learn from a
training dataset, allowing them to recognize and classify
different facial features and expressions accurately. By
leveraging the power of ML, the system can understand and
respond to the emotions displayed by operators, enabling
dynamic adjustment of the motor's frequency.
B. Dataset
A dataset in machine learning refers to a collection
of labeled examples used to train and evaluate ML
algorithms. In the case of facial recognition-based
frequency control, a diverse dataset of facial images is
required to train the ML model accurately.
The dataset for facial recognition typically consists of a
large number of images representing various individuals
with different facial expressions. Each image is labeled with
corresponding emotions or expressions, such as happy, sad,
angry, or neutral. The dataset should include a wide range
of facial variations, lighting conditions, and backgrounds to
ensure the model's robustness and generalization ability.
To create an effective dataset, careful data collection,
labeling, and preprocessing steps are necessary. This may
involve capturing facial images using high-resolution
cameras, manually annotating the images with the
corresponding emotions, and ensuring the dataset's balance
and diversity.
Once the dataset is prepared, it is used to train the ML
model, allowing it to learn the complex relationships
between facial features and expressions. The trained model
can then be deployed to analyze real-time facial expressions
and make frequency adjustments, accordingly, enabling
precise motor control based on the emotional cues displayed
by the operators. In our case, around 100 pictures were taken
of each member.
Fig 3.1 Labeled Dataset
C. Algorithm Used
YOLOv7, or You Only Look Once version 7, is an
object detection algorithm that builds upon the success of
previous versions of YOLO. The YOLO series is known
for its ability to perform real-time object detection by
processing the entire image in a single pass.
YOLOv7 follows a one-stage detection approach,
which means it directly predicts bounding boxes and class
probabilities for objects in a single step. This approach
contrasts with two-stage detectors like Faster R-CNN,
which separate the tasks of region proposal and object
classification. By eliminating the need for multiple stages,
YOLOv7 achieves faster inference times while maintaining
competitive accuracy.
The algorithm is based on a deep neural network
architecture, typically built with convolutional layers.
These layers enable YOLOv7 to extract high-level features
from the input image, which are crucial for accurate object
detection. YOLOv7 often incorporates residual
connections and other architectural improvements to
enhance the network's representational capacity.
To predict bounding boxes, YOLOv7 utilizes anchor-
based object detection. It starts by dividing the input image
into a grid of cells. Each cell is responsible for predicting a
fixed number of bounding boxes. These bounding boxes
are associated with predefined anchor boxes of various
sizes and aspect ratios. For each anchor box, YOLOv7
predicts the coordinates of the bounding box relative to the
cell and computes the confidence score for object presence,
as well as the class probabilities for different object
categories.
Overall, YOLOv7 is a powerful object detection
algorithm that combines efficient design principles with
advanced techniques. Its ability to provide real-time object
detection with impressive accuracy makes it well-suited for
various applications, including autonomous driving,
surveillance systems, and object recognition in complex
scenes.
Fig 3.2 CNN Architecture
D. Results/Plots/conclusion
The dataset of more than 100 images of each member was
created, and the algorithm was able to provide us with an
accuracy of about 80%-90%. The results are displayed in
the Fig. below.

Fig 3.3 Inference (83% accuracy)
IV. COMMUNICATION
A. Communication model used
In the project, the ESP-32 module was utilized for
wireless communication. The ESP-32 is a powerful Wi-Fi
and Bluetooth-enabled microcontroller module widely used
in Internet of Things (IoT) applications. It integrates a dual-
core processor, Wi-Fi and Bluetooth connectivity, and
various input/output (I/O) pins, making it an ideal choice for
wireless communication in the project.
Here's a general overview of how the ESP-32 works for
wireless communication:
1. Wi-Fi Connectivity: The ESP-32 module
incorporates Wi-Fi capabilities, allowing it to
connect to a local network or act as an access point.
It can establish a wireless connection with other
devices or connect to the internet for data
exchange.
2. Bluetooth Connectivity: In addition to Wi-Fi, the
ESP-32 module also supports Bluetooth
communication. It can establish Bluetooth
connections with other devices, enabling seamless
communication and data transfer.
3. Programming and Configuration: The ESP-32
module can be programmed using various
development environments, such as the Arduino
IDE or Espressif's official development
framework. This allows developers to write code
to control the module's functionalities and
configure its wireless communication parameters.
4. Wireless Data Transfer: With the ESP-32 module,
wireless data transfer is achieved by utilizing the
Wi-Fi or Bluetooth protocols. The module can
send and receive data packets wirelessly, allowing
it to transmit information to other devices within
its range.
5. Integration with Other Components: In the project,
the ESP-32 module is likely integrated with other
hardware components, such as the Arduino board
or sensors. This integration enables the ESP-32 to
receive data from the facial recognition system or
motor control unit and wirelessly transmit it to
other devices for further processing or display.
6. Communication Protocols: The ESP-32 module
supports various communication protocols,
including TCP/IP, HTTP, MQTT, and WebSocket.
These protocols facilitate seamless and reliable
data transmission between the ESP-32 module and
other devices or servers.
By leveraging the ESP-32's wireless capabilities, the
project achieved wireless communication between the facial
recognition system, motor control unit (Arduino), and
potentially other devices or systems. This wireless
communication allowed for real-time data exchange and
enabled remote control and monitoring of the motor driver
frequency adjustments based on the analyzed facial
expressions.
B. Protocol Used
The ESP-32 module utilizes the Wi-Fi protocol for wireless
communication. Wi-Fi (Wireless Fidelity) is a widely
adopted protocol that enables devices to connect and
communicate wirelessly within a local area network (LAN)
or with the internet. Here's an overview of how the ESP-32
utilizes the Wi-Fi protocol for communication:
1. Wi-Fi Connectivity: The ESP-32 module is
equipped with built-in Wi-Fi capabilities,
allowing it to connect to Wi-Fi networks as a
client or act as an access point.
2. Network Configuration: To establish a Wi-Fi
connection, the ESP-32 module needs to be
configured with the appropriate network
credentials, such as the network SSID (Service Set
Identifier) and password. This information is
typically provided through the device's firmware
or programmatically set during the initialization
process.
3. Network Discovery: The ESP-32 module can scan
for available Wi-Fi networks within its range. It
can retrieve information about nearby networks,
including their names (SSIDs) and signal
strengths. This allows the module to choose and
connect to the desired network based on the
provided credentials.
4. Wi-Fi Client Mode: In client mode, the ESP-32
module connects to an existing Wi-Fi network,
similar to how a smartphone or computer connects
to a Wi-Fi hotspot. Once connected, the module
obtains an IP address from the network's DHCP
server, which enables it to communicate with
other devices on the same network or access the
internet.
5. Data Exchange: With Wi-Fi connectivity
established, the ESP-32 module can send and
receive data packets over the network. It can
communicate with other devices or servers within
the same Wi-Fi network using TCP/IP or other
application layer protocols such as HTTP, MQTT,
or WebSocket. This allows for bidirectional data
transfer and facilitates the exchange of
information between the ESP-32 and other
connected devices.
 6. Security: The ESP-32 supports various Wi-Fi output, which is then fed into the motor control system for
security protocols, including WEP, WPA, and precise and efficient control of the motor's frequency.
WPA2, to ensure secure communication over Wi-
Fi networks. These security mechanisms help
protect sensitive data from unauthorized access or
tampering.
By leveraging the Wi-Fi protocol, the ESP-32 module
enables wireless communication and connectivity,
allowing it to exchange data with other devices or servers
within the same Wi-Fi network. This capability facilitates
remote control, monitoring, and integration with other
systems, making it suitable for a wide range of IoT
applications.

V. HARDWARE

A. AC to DC converter
Fig 5.1: Rectifier
In this project, an AC to DC converter was implemented
to convert the alternating current (AC) input into direct
current (DC) to power the motor control system. Power
diodes with a 10A rating were utilized as rectifiers in the AC
to DC conversion process. Here's an overview of how the
AC to DC converter and power diodes function:
1. Rectification: The AC input from the power source
undergoes rectification, where the negative portion
of the AC waveform is converted into a positive
voltage. This process ensures that the output is a
unidirectional current.
2. Full-Wave Rectification: Full-wave rectification is
achieved by using a bridge rectifier circuit, which
typically consists of four diodes. In this project,
power diodes with a 10A rating were employed for
their capability to handle high current levels.
3. Diode Operation: Power diodes are semiconductor
devices that allow current to flow in one direction
while blocking it in the opposite direction. When
the AC input voltage is positive, two of the diodes
in the bridge rectifier conduct, providing a forward
path for current flow. Simultaneously, the other Fig 5.2: Rectifier Output
two diodes are reverse-biased and block the current
flow in the opposite direction.
4. Conversion to DC: As the AC waveform B. Motor driver IC
alternates, the conducting diodes switch
accordingly, allowing the positive portion of the In this project, although a motor driver IC was initially
AC waveform to pass through. This results in a considered, it was ultimately not used. Instead, MOSFETs
pulsating DC waveform with a frequency twice were chosen as an alternative approach for controlling the
that of the input AC voltage. However, it still motor. Several factors influenced this decision:
contains ripple or fluctuations. 1. Precision and Efficiency: MOSFETs offer precise
5. Filtering: To reduce the ripple and obtain smoother control over the motor's speed and direction. By
DC output, a filtering capacitor is typically adjusting the gate voltage, MOSFETs can regulate
connected in parallel to the load. The capacitor the current flow to the motor with high accuracy.
helps smooth out the pulsating waveform by This level of control allows for efficient operation
storing charge during the peak voltage periods and and better performance compared to using a motor
releasing it during the low voltage periods. driver IC.
By utilizing power diodes with a 10A rating in the AC 2. Power Handling Capability: MOSFETs are
to DC converter, the project ensures that the diodes can capable of handling high current and voltage
handle high current levels effectively. This enables the levels, making them suitable for driving motors
conversion of AC input into a rectified and smoothed DC with varying power demands. This feature ensures
 that the control system can handle the motor's
requirements without the limitations imposed by
the current ratings of a motor driver IC.
By leveraging MOSFETs for motor control, the project
achieved precise and efficient regulation of the motor's
speed and direction. This decision offered greater control
flexibility, integration options, and power handling
capabilities, while also contributing to the project's
research goals in advancing motor control systems through
novel methodologies and components.
C. H-bridge description and results
In this project, an H-bridge configuration was utilized for
motor control. The H-bridge is a circuit topology
commonly used to control the direction and speed of DC
motors. It consists of four switching devices, typically
MOSFETs or transistors, arranged in a configuration that
allows bidirectional current flow through the motor. Here's
a description of the H-bridge and the results obtained:
1. Switching Devices: The H-bridge incorporates
four switching devices arranged in two pairs. Each
pair consists of two complementary switches,
typically labeled as high-side and low-side
switches. These switches can be MOSFETs,
transistors, or even specialized motor driver ICs.
2. Direction Control: By selectively activating the
high-side and low-side switches, the H-bridge can
control the motor's direction. For instance,
activating one pair while keeping the other pair
deactivated allows current to flow in one
direction, while reversing the activation pattern
changes the direction of current flow.
3. Speed Control: The H-bridge also enables speed
control by implementing pulse width modulation
(PWM). By rapidly switching the switches on and
off at varying duty cycles, the effective voltage
and current applied to the motor are adjusted. This
PWM technique allows for precise speed control.
Results:
1. Bidirectional Motor Control: The H-bridge
configuration successfully achieved bidirectional
control of the motor. By activating the appropriate
switches, the motor could be made to rotate in
either clockwise or counterclockwise directions,
providing versatility in motor operation.
2. Speed Regulation: Through the implementation of
pulse width modulation, the H-bridge allowed for
fine-tuned speed control. By adjusting the duty
cycle of the PWM signal, the effective voltage
applied to the motor could be controlled, resulting
in precise speed regulation across a wide range of
operating speeds.
3. Efficient Power Conversion: The H-bridge circuit
minimized power losses by utilizing the switching
nature of the switches. When the switches were
fully on, they presented minimal resistance,
maximizing the efficiency of power conversion
from the DC supply to the motor.
4. Overcurrent Protection: To protect the motor and
the H-bridge circuit from overcurrent conditions,
appropriate current sensing and protective
measures, such as fuses or current-limiting
devices, were incorporated. These measures
ensured safe operation and prevented damage to
the motor and circuitry.
The implementation of the H-bridge configuration
demonstrated effective bidirectional control and precise
speed regulation of the motor. The combination of the H-
bridge circuit with pulse width modulation provided
versatility, efficiency, and reliable operation, making it a
suitable choice for motor control applications.
D. Final Hardware Results
In the hardware section of the project, several key
components and configurations were implemented to
achieve motor control. The H-bridge configuration,
utilizing MOSFETs as switching devices, played a crucial
role in bidirectional control and speed regulation of the
motor. By activating the appropriate switches, the motor
could be made to rotate in either direction. The use of pulse
width modulation (PWM) allowed for precise speed control
by adjusting the duty cycle of the PWM signal. This
combination of the H-bridge and PWM facilitated versatile
and efficient motor operation. Additionally, the power
diodes used in the AC to DC converter ensured the
conversion of AC input to DC power for the motor control
system. The integration of the ESP-32 module enabled
wireless communication, providing connectivity and data
exchange capabilities. Overall, the hardware
implementation successfully achieved bidirectional motor
control, precise speed regulation, efficient power
conversion, and wireless communication, contributing to
the overall success of the project.
APPENDIX
IMPORT SOCKET
IMPORT TIME
IMPORT ARGPARSE
IMPORT TIME
FROM PATHLIB IMPORT PATH
IMPORT CV2
 IMPORT TORCH

IMPORT TORCH.BACKENDS.CUDNN AS CUDNN IF TRACE:

FROM NUMPY IMPORT RANDOM MODEL = TRACEDMODEL(MODEL, DEVICE,

OPT.IMG_SIZE)

FROM MODELS.EXPERIMENTAL IMPORT ATTEMPT_LOAD

IF HALF:
FROM UTILS.DATASETS IMPORT LOADSTREAMS,
LOADIMAGES MODEL.HALF() # TO FP16
FROM UTILS.GENERAL IMPORT CHECK_IMG_SIZE,
CHECK_REQUIREMENTS, CHECK_IMSHOW,
NON_MAX_SUPPRESSION, APPLY_CLASSIFIER, \
# SECOND-STAGE CLASSIFIER
CLASSIFY = FALSE
SCALE_COORDS, XYXY2XYWH, STRIP_OPTIMIZER,
SET_LOGGING, INCREMENT_PATH IF CLASSIFY:
FROM UTILS.PLOTS IMPORT PLOT_ONE_BOX MODELC = LOAD_CLASSIFIER(NAME='RESNET101',
N=2) # INITIALIZE
FROM UTILS.TORCH_UTILS IMPORT SELECT_DEVICE,
LOAD_CLASSIFIER, TIME_SYNCHRONIZED, TRACEDMODEL
MODELC.LOAD_STATE_DICT(TORCH.LOAD('WEIGHTS/RESNE
T101.PT',
MAP_LOCATION=DEVICE)['MODEL']).TO(DEVICE).EVAL()

DEF DETECT(SAVE_IMG=FALSE):

SOURCE, WEIGHTS, VIEW_IMG, SAVE_TXT, IMGSZ, # SET DATALOADER

TRACE = OPT.SOURCE, OPT.WEIGHTS, OPT.VIEW_IMG,
VID_PATH, VID_WRITER = NONE, NONE
OPT.SAVE_TXT, OPT.IMG_SIZE, NOT OPT.NO_TRACE
IF WEBCAM:
SAVE_IMG = NOT OPT.NOSAVE AND NOT
SOURCE.ENDSWITH('.TXT') # SAVE INFERENCE IMAGES VIEW_IMG = CHECK_IMSHOW()
WEBCAM = SOURCE.ISNUMERIC() OR CUDNN.BENCHMARK = TRUE # SET TRUE TO SPEED
SOURCE.ENDSWITH('.TXT') OR UP CONSTANT IMAGE SIZE INFERENCE
SOURCE.LOWER().STARTSWITH(
DATASET = LOADSTREAMS(SOURCE,
('RTSP://', 'RTMP://', 'HTTP://', 'HTTPS://')) IMG_SIZE=IMGSZ, STRIDE=STRIDE)

ELSE:
# DIRECTORIES DATASET = LOADIMAGES(SOURCE,
IMG_SIZE=IMGSZ, STRIDE=STRIDE)
SAVE_DIR =
PATH(INCREMENT_PATH(PATH(OPT.PROJECT) / OPT.NAME,
EXIST_OK=OPT.EXIST_OK)) # INCREMENT RUN
# GET NAMES AND COLORS
(SAVE_DIR / 'LABELS' IF SAVE_TXT ELSE
SAVE_DIR).MKDIR(PARENTS=TRUE, EXIST_OK=TRUE) # NAMES = MODEL.MODULE.NAMES IF HASATTR(MODEL,
MAKE DIR 'MODULE') ELSE MODEL.NAMES
COLORS = [[RANDOM.RANDINT(0, 255) FOR _ IN
RANGE(3)] FOR _ IN NAMES]
# INITIALIZE
SET_LOGGING()
# RUN INFERENCE
DEVICE = SELECT_DEVICE(OPT.DEVICE)
IF DEVICE.TYPE != 'CPU':
HALF = DEVICE.TYPE != 'CPU' # HALF PRECISION ONLY
SUPPORTED ON CUDA MODEL(TORCH.ZEROS(1, 3, IMGSZ,
IMGSZ).TO(DEVICE).TYPE_AS(NEXT(MODEL.PARAMETERS())
)) # RUN ONCE
# LOAD MODEL OLD_IMG_W = OLD_IMG_H = IMGSZ
MODEL = ATTEMPT_LOAD(WEIGHTS, OLD_IMG_B = 1
MAP_LOCATION=DEVICE) # LOAD FP32 MODEL

STRIDE = INT(MODEL.STRIDE.MAX()) # MODEL STRIDE

T0 = TIME.TIME()
IMGSZ = CHECK_IMG_SIZE(IMGSZ, S=STRIDE) # CHECK
IMG_SIZE FOR PATH, IMG, IM0S, VID_CAP IN DATASET:
 IMG = TORCH.FROM_NUMPY(IMG).TO(DEVICE)
IMG = IMG.HALF() IF HALF ELSE IMG.FLOAT()
UINT8 TO FP16/32
IMG /= 255.0 # 0 - 255 TO 0.0 - 1.0
IF IMG.NDIMENSION() == 3:
IMG = IMG.UNSQUEEZE(0)
# WARMUP
IF DEVICE.TYPE != 'CPU' AND (OLD_IMG_B !=
IMG.SHAPE[0] OR OLD_IMG_H != IMG.SHAPE[2] OR
OLD_IMG_W != IMG.SHAPE[3]):
OLD_IMG_B = IMG.SHAPE[0]
OLD_IMG_H = IMG.SHAPE[2]
OLD_IMG_W = IMG.SHAPE[3]
FOR I IN RANGE(3):
MODEL(IMG, AUGMENT=OPT.AUGMENT)[0]
# INFERENCE
T1 = TIME_SYNCHRONIZED()
WITH TORCH.NO_GRAD(): # CALCULATING
GRADIENTS WOULD CAUSE A GPU MEMORY LEAK
PRED = MODEL(IMG, AUGMENT=OPT.AUGMENT)[0]
T2 = TIME_SYNCHRONIZED()
# APPLY NMS
PRED = NON_MAX_SUPPRESSION(PRED,
OPT.CONF_THRES, OPT.IOU_THRES, CLASSES=OPT.CLASSES,
AGNOSTIC=OPT.AGNOSTIC_NMS)
T3 = TIME_SYNCHRONIZED()
# APPLY CLASSIFIER
IF CLASSIFY:
PRED = APPLY_CLASSIFIER(PRED, MODELC, IMG,
IM0S)
# PROCESS DETECTIONS
FOR I, DET IN ENUMERATE(PRED):
IMAGE
IF WEBCAM: # BATCH_SIZE >= 1
P, S, IM0, FRAME = PATH[I], '%G: ' % I,
IM0S[I].COPY(), DATASET.COUNT
ELSE:
P, S, IM0, FRAME = PATH, '', IM0S,
GETATTR(DATASET, 'FRAME', 0)
P = PATH(P) # TO PATH
SAVE_PATH = STR(SAVE_DIR / P.NAME) # IMG.JPG
# TXT_PATH = STR(SAVE_DIR / 'LABELS' / P.STEM) +
('' IF DATASET.MODE == 'IMAGE' ELSE F'_{FRAME}') #
IMG.TXT
GN = TORCH.TENSOR(IM0.SHAPE)[[1, 0, 1, 0]] #
NORMALIZATION GAIN WHWH
IF LEN(DET):
# RESCALE BOXES FROM IMG_SIZE TO IM0 SIZE
DET[:, :4] = SCALE_COORDS(IMG.SHAPE[2:],
DET[:, :4], IM0.SHAPE).ROUND()
# PRINT RESULTS
FOR C IN DET[:, -1].UNIQUE():
N = (DET[:, -1] == C).SUM() # DETECTIONS PER
CLASS
S += F"{N} {NAMES[INT(C)]}{'S' * (N > 1)}, " #
ADD TO STRING
# WRITE RESULTS
FOR *XYXY, CONF, CLS IN REVERSED(DET):
IF SAVE_TXT: # WRITE TO FILE
XYWH =
(XYXY2XYWH(TORCH.TENSOR(XYXY).VIEW(1, 4)) /
GN).VIEW(-1).TOLIST() # NORMALIZED XYWH
LINE = (CLS, *XYWH, CONF) IF
OPT.SAVE_CONF ELSE (CLS, *XYWH) # LABEL FORMAT
WITH OPEN(TXT_PATH + '.TXT', 'A') AS F:
F.WRITE(('%G ' * LEN(LINE)).RSTRIP() %
LINE + '\N')
IF SAVE_IMG OR VIEW_IMG: # ADD BBOX TO
IMAGE
LABEL = F'{NAMES[INT(CLS)]} {CONF:.2F}'
PLOT_ONE_BOX(XYXY, IM0, LABEL=LABEL,
COLOR=COLORS[INT(CLS)], LINE_THICKNESS=1)
# PRINT TIME (INFERENCE + NMS)
#PRINT(F'{NAMES[INT(C)] IS DETECTED}{S}DONE.
# DETECTIONS PER ({(1E3 * (T2 - T1)):.1F}MS) INFERENCE, ({(1E3 * (T3 -
T2)):.1F}MS) NMS')
PRINT(F'{NAMES[INT(C)]} IS DETECTED')
# DEFINE THE IP ADDRESS AND PORT NUMBER FOR
THE ESP32
IP_ADDRESS = "10.1.154.137"
PORT = 53
# CREATE A SOCKET OBJECT AND CONNECT TO THE
ESP32
 X = SOCKET.SOCKET(SOCKET.AF_INET,
SOCKET.SOCK_STREAM)
X.CONNECT((IP_ADDRESS, PORT))
DELAY = NAMES[INT(C)]
S=
F"\N{LEN(LIST(SAVE_DIR.GLOB('LABELS/*.TXT')))} LABELS
SAVED TO {SAVE_DIR / 'LABELS'}" IF SAVE_TXT ELSE ''
#PRINT(F"RESULTS SAVED TO {SAVE_DIR}{S}")

X.SENDALL(DELAY.ENCODE())
PRINT(F'DONE. ({TIME.TIME() - T0:.3F}S)')
#DATA = X.RECV(1024)
#IF DATA.DECODE() == "ACK":
PRINT(F' DATA SENT SUCCESSFULLY')
IF __NAME__ == '__MAIN__':
TIME.SLEEP(1)
PARSER = ARGPARSE.ARGUMENTPARSER()

PARSER.ADD_ARGUMENT('--WEIGHTS', NARGS='+',
TYPE=STR, DEFAULT='YOLOV7.PT', HELP='MODEL.PT
# STREAM RESULTS PATH(S)')

IF VIEW_IMG: PARSER.ADD_ARGUMENT('--SOURCE', TYPE=STR,

DEFAULT='INFERENCE/IMAGES', HELP='SOURCE') #
CV2.IMSHOW(STR(P), IM0) FILE/FOLDER, 0 FOR WEBCAM
CV2.WAITKEY(1) # 1 MILLISECOND PARSER.ADD_ARGUMENT('--IMG-SIZE', TYPE=INT,
DEFAULT=640, HELP='INFERENCE SIZE (PIXELS)')

# SAVE RESULTS (IMAGE WITH DETECTIONS) PARSER.ADD_ARGUMENT('--CONF-THRES',

TYPE=FLOAT, DEFAULT=0.25, HELP='OBJECT CONFIDENCE
IF SAVE_IMG: THRESHOLD')
IF DATASET.MODE == 'IMAGE': PARSER.ADD_ARGUMENT('--IOU-THRES', TYPE=FLOAT,
CV2.IMWRITE(SAVE_PATH, IM0) DEFAULT=0.45, HELP='IOU THRESHOLD FOR NMS')

PRINT(F" THE IMAGE WITH THE RESULT IS PARSER.ADD_ARGUMENT('--DEVICE', DEFAULT='',

SAVED IN: {SAVE_PATH}") HELP='CUDA DEVICE, I.E. 0 OR 0,1,2,3 OR CPU')

ELSE: # 'VIDEO' OR 'STREAM' PARSER.ADD_ARGUMENT('--VIEW-IMG',

ACTION='STORE_TRUE', HELP='DISPLAY RESULTS')
IF VID_PATH != SAVE_PATH: # NEW VIDEO
PARSER.ADD_ARGUMENT('--SAVE-TXT',
VID_PATH = SAVE_PATH ACTION='STORE_TRUE', HELP='SAVE RESULTS TO *.TXT')
IF ISINSTANCE(VID_WRITER, PARSER.ADD_ARGUMENT('--SAVE-CONF',
CV2.VIDEOWRITER): ACTION='STORE_TRUE', HELP='SAVE CONFIDENCES IN --
SAVE-TXT LABELS')
VID_WRITER.RELEASE() # RELEASE
PREVIOUS VIDEO WRITER PARSER.ADD_ARGUMENT('--NOSAVE',
ACTION='STORE_TRUE', HELP='DO NOT SAVE
IF VID_CAP: # VIDEO
IMAGES/VIDEOS')
FPS =
PARSER.ADD_ARGUMENT('--CLASSES', NARGS='+',
VID_CAP.GET(CV2.CAP_PROP_FPS)
TYPE=INT, HELP='FILTER BY CLASS: --CLASS 0, OR --CLASS 0
W= 2 3')
INT(VID_CAP.GET(CV2.CAP_PROP_FRAME_WIDTH))
PARSER.ADD_ARGUMENT('--AGNOSTIC-NMS',
H= ACTION='STORE_TRUE', HELP='CLASS-AGNOSTIC NMS')
INT(VID_CAP.GET(CV2.CAP_PROP_FRAME_HEIGHT))
PARSER.ADD_ARGUMENT('--AUGMENT',
ELSE: # STREAM ACTION='STORE_TRUE', HELP='AUGMENTED INFERENCE')

FPS, W, H = 30, IM0.SHAPE[1], PARSER.ADD_ARGUMENT('--UPDATE',

IM0.SHAPE[0] ACTION='STORE_TRUE', HELP='UPDATE ALL MODELS')

SAVE_PATH += '.MP4' PARSER.ADD_ARGUMENT('--PROJECT',

DEFAULT='RUNS/DETECT', HELP='SAVE RESULTS TO
VID_WRITER =
PROJECT/NAME')
CV2.VIDEOWRITER(SAVE_PATH,
CV2.VIDEOWRITER_FOURCC(*'MP4V'), FPS, (W, H)) PARSER.ADD_ARGUMENT('--NAME', DEFAULT='EXP',
HELP='SAVE RESULTS TO PROJECT/NAME')
VID_WRITER.WRITE(IM0)
PARSER.ADD_ARGUMENT('--EXIST-OK',
ACTION='STORE_TRUE', HELP='EXISTING PROJECT/NAME OK,
IF SAVE_TXT OR SAVE_IMG: DO NOT INCREMENT')
 PARSER.ADD_ARGUMENT('--NO-TRACE',
ACTION='STORE_TRUE', HELP='DON`T TRACE MODEL')

OPT = PARSER.PARSE_ARGS()

PRINT(OPT)

#CHECK_REQUIREMENTS(EXCLUDE=('PYCOCOTOOLS',
'THOP'))

WITH TORCH.NO_GRAD():

IF OPT.UPDATE: # UPDATE ALL MODELS (TO FIX

SOURCECHANGEWARNING)
FOR OPT.WEIGHTS IN ['YOLOV7.PT']:

DETECT()

STRIP_OPTIMIZER(OPT.WEIGHTS)

ELSE:

DETECT()