Vehicle type robot voice navigation control system and control method thereof

Abstract

The invention relates to the technical field of voice recognition and natural language processing, in particular to a vehicle type robot voice navigation control system and a control method thereof.The method takes voice as a man-machine interaction entrance and comprises the following steps that S1, environment audio is continuously monitored and preprocessed, including noise reduction, reverberation removal, pre-emphasis and framing windowing; when a preset wake-up word is detected, sending a wake-up signal to a main control unit through a serial port, and entering a command identification window with a fixed duration; s2, in the command recognition window, performing automatic voice recognition and natural language processing on the input voice, analyzing user intentions and key entities, and classifying analysis results into a mapping instruction, a motion control instruction or a navigation instruction; according to the invention, an integrated system with off-line voice as an entrance, a modular architecture as a core and closed-loop control and multi-mode feedback as guarantee is constructed, so that the limitation of the prior art is effectively overcome.

Description

Technical Field

[0001] This invention relates to a voice navigation control system and control method for a vehicle-type robot, and particularly to a voice navigation control system and control method for a vehicle-type robot, belonging to the field of speech recognition and natural language processing technology. Background Technology

[0002] In existing technologies, the control of vehicle robots mostly relies on remote controls, pre-programmed scripts, or touch operations on mobile applications (APPs). These methods all require users to perform active and concrete operations, lacking a natural and intuitive human-computer interaction experience. Although some advanced systems have introduced basic voice command control and can recognize simple commands such as "forward" and "turn left", their functions are usually limited to direct motion control, with limited semantic understanding capabilities. They cannot handle complex natural language commands with contextual information. At the same time, the mapping and navigation functions of these systems often rely on pre-configured environmental maps or require professionals to perform complex point marking and path planning in specific software. Ordinary users find it difficult to directly participate in and control the entire intelligent operation process. However, the aforementioned existing technologies have significant limitations. First, traditional interaction methods cannot achieve natural "what you say is what you get" commands, resulting in high user learning costs and an inability to directly trigger the robot's autonomous task chain through advanced semantic commands (such as "go to the kitchen"). Second, existing voice control systems largely rely on online voice services, which cannot operate stably in scenarios with poor network signals or for privacy reasons, and lack deep integration with the robot's autonomous functions (such as SLAM mapping and global path planning). Furthermore, the system's status is opaque during task execution, making it difficult for users to know in a timely manner whether commands have been executed correctly, the progress of the task, or how the system reacts when encountering obstacles, leading to a poor user experience and low trust. In addition, the various modules of the system (perception, decision-making, and execution) are usually tightly coupled, lacking standardized interfaces and closed-loop feedback mechanisms, resulting in insufficient system robustness and susceptibility to interference and failure in dynamic environments. Therefore, there is an urgent need to improve a voice navigation control system and its control method for vehicle-type robots to solve the aforementioned problems. Summary of the Invention

[0003] The purpose of this invention is to provide a voice navigation control system and control method for a vehicle-mounted robot, addressing the following issues: First, traditional interaction methods cannot achieve natural "what you say is what you get" commands, resulting in high user learning costs and the inability to directly trigger the robot's autonomous task chain through advanced semantic commands (such as "go to the kitchen"). Second, existing voice control systems largely rely on online voice services, which cannot operate stably in scenarios with poor network signals or for privacy reasons, and lack deep integration with the robot's autonomous functions (such as SLAM mapping and global path planning). Third, the system's status is opaque during task execution, making it difficult for users to know in a timely manner whether commands have been executed correctly, the progress of the task, or how the system reacts when encountering obstacles, leading to a poor user experience and low trust. Furthermore, the various modules of the system (perception, decision-making, and execution) are usually tightly coupled, lacking standardized interfaces and closed-loop feedback mechanisms, resulting in insufficient system robustness and susceptibility to interference and failure in dynamic environments.

[0004] To achieve the above objectives, the present invention provides the following technical solution: A voice navigation control system and method for a vehicle-mounted robot, wherein the method uses voice as the human-computer interaction interface, and includes the following steps: S1. Continuously monitor ambient audio and perform preprocessing, including noise reduction, dereverberation, pre-emphasis, and frame windowing; when a preset wake-up word is detected, send a wake-up signal to the main control unit via serial port and enter a command recognition window of fixed duration; S2. In the command recognition window, perform automatic speech recognition and natural language processing on the input speech, parse out the user intent and key entities, and classify the parsing results into mapping commands, motion control commands or navigation commands. S3. For the mapping command, start the SLAM module and drive the LiDAR, odometer and IMU sensor to collect data. Based on particle filtering and scan matching, perform incremental map construction in a loop. When the map quality judgment conditions are met, persist the map as a map file. S4. For navigation commands, the target name is parsed and the corresponding coordinates are queried from the location database. The static map is loaded through the navigation scheduling module and adaptive Monte Carlo positioning is performed. The global planner generates the global path, and the local planner generates real-time executable speed commands. These commands are then published to the chassis controller via the cmd_vel topic or serial port protocol. S5. During hardware execution, receive data from the motor encoder, odometer and IMU in real time, perform multi-sensor fusion and state estimation, and correct the execution deviation according to the closed-loop control strategy until the error between the actual state and the target state meets the preset tolerance or navigation failure is determined. S6. When recognition fails, navigation is obstructed, or an anomaly occurs, trigger corresponding feedback and recovery behaviors, including voice prompts, rotating in place, reversing slightly, clearing the cost map, and waiting for manual intervention. S7 provides feedback to users on key events through TTS voice broadcasting, RGB light strips, and buzzers in a multimodal manner.

[0005] Preferably, the wake-up word detection operates continuously in a low-power mode during the listening state. When a wake-up word is detected, a unique wake-up message is sent to the main control unit via the serial port, and a command recognition window of a fixed duration is opened after wake-up, preferably 15 seconds.

[0006] Preferably, in S2, speech recognition is performed locally offline, recognizing a predefined limited set of instructions; when recognition is successful, a unique command identifier is sent to the main control unit via serial port; if recognition fails or times out, no command identifier is sent and the system automatically resets to standby listening state.

[0007] Preferably, in S3, the mapping process adopts the gmappingSLAM algorithm based on particle filtering, which includes particle set initialization, motion model prediction, scan matching, weight calculation, resampling and map update steps; and monitors the map quality in real time during operation, including particle weight distribution, scan matching score, number of loop closure detections and map coverage. When the map quality is lower than a preset threshold, the SLAM parameters are automatically adjusted.

[0008] Preferably, in S4, the navigation scheduling process is implemented based on the ROS navigation stack, using adaptive Monte Carlo positioning for real-time pose estimation, using a global planner to generate a global path, using a local planner to generate local velocity commands, and maintaining global and local cost maps; when local planning fails, a predefined recovery behavior sequence is triggered, and after multiple unsuccessful recovery attempts, navigation failure is marked and the user is prompted via TTS voice.

[0009] Preferably, the state estimation employs multi-sensor fusion of odometry and IMU, implemented through Kalman filtering or the EKF or UKF algorithm from the robot_localization package. The fused odometry information is used to publish the odom topic and serves as input for localization and closed-loop control. The closed-loop control calculates the deviation e, and the formula for calculating the deviation e is: e = target velocity / position - actual velocity / position; It generates corrections for the motor duty cycle or speed command using proportional, integral, and derivative terms until the error meets the preset accuracy.

[0010] Preferably, the system uses a standardized frame format in the communication protocol for command issuance and status feedback. The frame format includes a frame header, device identifier, command or status type, parameter data, and verification, and is implemented through hexadecimal encoding. The multimodal feedback includes TTS voice broadcast, RGB light bar color or mode switching, and buzzer frequency prompts, used to provide feedback on key statuses to the user.

[0011] Preferably, it includes: a voice interaction module, used to collect ambient audio, perform wake word detection, automatic speech recognition and natural language understanding, and send a wake-up signal or command identifier to the central scheduling unit via serial port when wake-up or recognition is successful; The central scheduling unit is configured to run mapping and navigation scheduling logic based on the ROS platform. It can receive commands from the voice interaction module and call the SLAM module or navigation module according to the command type. It manages the location database, path planning, local or global cost map and recovery behavior logic. The underlying execution unit, including the motor driver, wheeled chassis, encoder and power management module, is used to respond to motion commands issued by the central scheduling unit and return odometer and status data; Sensor arrays, including lidar, odometers or motor encoders, IMUs, and temperature or voltage sensors, are used to provide real-time sensing data for SLAM, positioning, and closed-loop control. The communication interface is used to realize serial communication between the voice module and the central scheduling unit, as well as the transmission of control commands and status feedback between the central scheduling unit and the underlying execution unit. The system is also equipped with a TTS unit for voice broadcasting and an RViz interface for visual debugging.

[0012] Preferably, the voice interaction module includes automatic level control, noise suppression, and echo cancellation functions, and supports predefined command sets and wake-up word detection using an offline ASR engine; the central scheduling unit is implemented based on the ROS platform, running the gmappingSLAM algorithm, AMCL positioning, and move_base navigation stack; the underlying execution unit is equipped with closed-loop control capabilities, receiving speed commands based on an encoder and PID controller via cmd_vel or serial port protocol; the system supports persistently saving maps in map.pgm and map.yaml formats for subsequent navigation loading.

[0013] This invention has at least the following beneficial effects: This invention effectively overcomes the limitations of existing technologies by constructing an integrated system with offline voice as the entry point, a modular architecture as the core, and closed-loop control and multimodal feedback as guarantees. Firstly, it achieves natural "what you say is what you get" interaction, allowing users to directly trigger and execute complex autonomous task chains through advanced semantic commands such as "go to the kitchen," requiring no professional knowledge or cumbersome operations, greatly lowering the barrier to entry. Secondly, the system possesses high autonomy, robustness, and privacy security. The deeply integrated offline speech recognition engine eliminates dependence on the network, while real-time mapping based on SLAM, AMCL localization, and hierarchical processing... Path planning endows the robot with strong environmental awareness and autonomous navigation capabilities in unknown or dynamic environments. Furthermore, the system significantly improves user experience and trust through a transparent state design across the entire chain. From TTS voice broadcasts and light / buzzer prompts to RVIZ visualization, key states and abnormal situations can be fed back to the user in real time and from multiple dimensions. Finally, modular design and standardized communication interfaces ensure the reliability and scalability of the system. The various functional modules interact through clear interfaces and, combined with sensor fusion and PID closed-loop control, form a stable system with rapid response and strong anti-interference capabilities. Attached Figure Description

[0014] Figure 1 This is a system block diagram of a vehicle robot voice navigation control system according to the present invention; Figure 2 This is a flowchart of the voice recognition process of a vehicle robot voice navigation control system according to the present invention; Figure 3 This is a flowchart illustrating the environmental mapping process of a voice navigation control system for a vehicle-type robot according to the present invention. Figure 4 This is a flowchart illustrating the autonomous navigation process of a vehicle-mounted robot voice navigation control system according to the present invention. Figure 5 This is a flowchart illustrating the mapping algorithm of this invention. Figure 6 This is a flowchart of the navigation algorithm of the present invention. Detailed Implementation

[0015] The following will describe in detail the implementation of this application with reference to the accompanying drawings and embodiments, so that the implementation process of how this application uses technical means to solve technical problems and achieve technical effects can be fully understood and implemented accordingly.

[0016] Specifically, such as Figure 1-6 As shown, this relates to a voice navigation control system for a vehicle-type robot and its control method. Example

[0017] 1. System Hardware Configuration The hardware structure of the vehicle robot system in this embodiment is as follows: Figure 1 As shown, it mainly includes the following parts: Voice Interaction Module: The core of this module is an offline voice recognition board based on the CI1302 chip. It features two onboard digital MEMS microphones forming a small microphone array to capture ambient audio. The chip incorporates a BNPU V3 neural processing unit, supporting low-power wake-word detection and offline recognition of 300 local command words, with a recognition response time ≤300ms. The module provides a UART serial port for communication with the main control board. Central scheduling unit: It uses an embedded computing board (such as Jetson Nano or RK3399) equipped with Ubuntu and ROS (Robot Operating System) Melodic as the main controller; this unit runs the core logic of the system, including voice command distribution, gmappingSLAM algorithm, move_base navigation stack, AMCL positioning algorithm and communication management with other modules; Sensor group: 1) LiDAR: A 360° two-dimensional LiDAR (such as RPLIDAR A1 or YDLIDAR X4) is used. It is connected to the main control board via USB interface and publishes the / scan topic in real time to provide distance information of the surrounding environment. 2) Inertial Measurement Unit (IMU): Employs an ICM20948 nine-axis IMU sensor, connected to the main control board via an I2C interface, providing three-axis acceleration, three-axis angular velocity, and three-axis magnetometer data; 3) Odometer / Motor Encoder: Each of the robot's four Mecanum wheels is equipped with a magnetic encoder, which outputs pulses via AB phases. The timer of the STM32 main control chip performs a four-fold frequency count to accurately measure the rotation speed and rotation distance of each wheel. Low-level execution unit: 1) Main control and drive: A control board based on STM32F103RCT6 receives motion commands from the central scheduling unit via CAN or UART (cmd_vel topic); STM32 generates 4 PWM signals to drive 4 A4950 full-bridge motor driver chips respectively, thereby controlling 4 DC geared motors; 2) Chassis: It adopts a four-Mecanum wheel omnidirectional moving chassis, which can realize forward and backward, lateral and rotational movements in a plane; Feedback and interaction devices: 1) TTS Unit: The speech recognition board integrates speech synthesis function and can be connected to a speaker through its audio output interface to announce the system status; 2) RGB LED strip: A programmable RGB LED strip that wraps around the robot's body, with color and brightness controlled by an STM32 microcontroller via PWM; 3) Buzzer: A passive buzzer connected to the STM32 can emit different frequencies of alert sounds; 4) Communication Interface: The voice interaction module communicates with the control board via UART serial port (baud rate 9600bps) following a custom protocol; the central scheduling unit (ROS master controller) communicates with the STM32 control board via ROS network, using standard topics such as / cmd_vel and / odom. 2. Detailed description of system workflow This embodiment uses the user commands "Xiao Zhen Xiao Zhen, start mapping" and "Xiao Zhen Xiao Zhen, go to the kitchen" as examples to explain the system's workflow in detail.

[0018] Scenario 1: Environmental Mapping Voice wake-up and recognition: When the user says "Xiao Zhen Xiao Zhen, start mapping", the microphone picks up the audio and the voice module performs preprocessing (noise reduction, de-reverberation, etc.). The low-power wake-up detection engine of the voice module recognizes the wake-up word "Xiao Zhen Xiao Zhen" and immediately sends the wake-up signal "WAKE_OK" to the STM32 control board via serial port. At the same time, it enters a command recognition state for 15 seconds. In command recognition mode, the module identifies and performs NLP parsing on "Start Mapping" to determine that it is a valid "Mapping Command". Then, it sends the unique command identifier "CMD_MAP_START" corresponding to the command to the STM32 control board via serial port. The STM32 control board publishes the instruction "CMD_MAP_START" as a custom ROS topic through the ROS serial_node. The central scheduling unit (ROS master controller) subscribes to this topic and starts the mapping process after receiving the instruction. SLAM mapping execution: Initialization: The central scheduling unit starts the gmapping node, which initializes a particle set containing 1000 particles. It is assumed that the robot's initial pose is the map origin (0,0,0). Data acquisition and processing loop: Motion model update: gmapping node subscription / odom topic (data comes from odometry information released by STM32 after merging encoder and IMU data), predict the new pose of each particle based on odometry data, and introduce uncertainty (particle diffusion). Scan matching: Nodes simultaneously subscribe to the / scan topic (LiDAR data) and match the current laser scan frame with the map maintained by each particle itself (using a grid-based scan matching algorithm), which greatly corrects pose spread caused by odometry errors. Weight calculation and resampling: Based on the matching degree between the laser data and each particle map, weights are assigned to the particles, and then resampling is performed to eliminate low-weight particles and replicate high-weight particles, so that the particle swarm is concentrated near the robot's real pose. Map Update: Using the current best pose estimate and laser data, update the occupied grid map maintained by all particles. Points hit by the laser beam are marked as "occupied", and areas traversed by the laser beam are marked as "idle". Map quality monitoring and exploration: The operator monitors the map building process in real time via RVIZ. gmapping internally monitors particle weight variance and scan matching score. In this embodiment, the operator remotely controls the robot's movement via keyboard or subsequent voice commands (such as "forward" or "turn left") to explore the entire environment. The system visualizes the map, robot pose, and laser point cloud using RVIZ. Map saving: Once the environment has been explored and the map is clearly and consistently displayed in RVIZ, the user says "Save map," and the voice module recognizes this and sends the "CMD_MAP_SAVE" command. Upon receiving the command, the central scheduling unit calls the map_saver node to save the current optimal map as map.pgm (image file) and map.yaml (configuration file) to the specified path.

[0019] Scenario 2: Point-to-point navigation Voice command parsing: When the user says "Xiao Zhen, Xiao Zhen, go to the kitchen," the voice module is awakened, recognizes "go to the kitchen" as a navigation command, and sends the command identifier "CMD_NAV_KITCHEN" to the STM32 control board via serial port, which is eventually received by the central scheduling unit.

[0020] Navigation initialization: The central scheduling unit starts the nodes required for navigation, including map_server (loads the previously saved map.pgm and map.yaml) and amcl node (used for positioning). After the amcl node is started, the particle filter algorithm is also used. Combining the current laser scanning data and the loaded static map, the robot gradually converges and determines the precise pose of the robot in the map. Goal setting and path planning: The central dispatch unit parses the "CMD_NAV_KITCHEN" command and queries its internally maintained location database, which pre-stores the map coordinates (e.g., x=5.0, y=3.0, θ=0.0) corresponding to the name "kitchen". The target coordinates are sent to the move_base node, which is the core scheduler of the ROS navigation stack. Global planning: move_base calls the global planner (such as global_planner, which uses the A* algorithm by default) to calculate an optimal global path from the starting point to the end point based on the static map, the robot's current position and the target position (displayed as a green line in RVIZ). Local planning and obstacle avoidance: move_base simultaneously calls a local planner (such as the DWA algorithm). The local planner combines real-time LiDAR data ( / scan) to generate a local cost map (which dynamically marks obstacles detected in real time). Guided by the global path, it calculates a safe and feasible speed command (linear velocity v) in the short term. x angular velocity ω); Motion execution and closed-loop control: move_base publishes the calculated (vx, ω) velocity command to the / cmd_vel topic; The STM32 control board subscribes to the / cmd_vel topic and sets it as the target speed. Closed-loop control: The STM32 reads the encoder data of the four motors at a frequency of 100Hz to calculate the real-time speed of the robot chassis. The control quantity is calculated by a PID controller (e.g., proportional coefficient Kp=0.5, integral coefficient Ki=0.01, derivative coefficient Kd=0.05): control quantity = Kp * e + Ki * ∫e dt + Kd * (de / dt), where e is the deviation between the target speed and the actual speed. The STM32 dynamically adjusts the PWM duty cycle output to the motors according to the control quantity to ensure that the robot accurately tracks the speed command. Meanwhile, STM32 publishes the fused encoder and IMU data as the / odom topic to provide feedback for amcl localization and move_base; Status feedback and exception handling: Multimodal feedback: TTS: At the start of navigation, the system announces "Heading to the kitchen" via voice; upon arrival, it announces "Arrived at the kitchen". Lighting: While driving, the RGB light strip displays a blue flowing effect; upon arrival, it turns green and stays on for 2 seconds; if a malfunction occurs, it flashes red. Buzzer: emits a short "beep" sound when a command is received; emits a long beep when navigation fails; Exception handling: Suppose the robot is blocked by a temporarily placed chair on its way to the kitchen; Recovery behavior: When the local planner cannot find a safe path, move_base will trigger a recovery behavior sequence: First, let the robot rotate in place (to try to get a new perspective). If this is ineffective, it will retreat slightly and clear the local cost map (to rule out possible sensor misjudgments), and then replan. Failure handling: If the path is still blocked after multiple recovery attempts, move_base will mark the navigation status as "failed". The central dispatch unit will then broadcast "The path is blocked and the kitchen cannot be reached" via TTS, and the lights will flash red.

[0021] 3. Communication Protocol Examples The system uses a standardized frame format for serial communication, for example: Downlink command frame (voice module -> STM32): FF 02 CMD_NAV_KITCHEN BB FF: Frame Header 02: Equipment Identifier (02 represents the main controller) CMD_NAV_KITCHEN: Instruction content (this is an example; the actual encoding is specific). BB: Checksum (XOR and OR CRC8, for example) Uplink status frame (STM32 -> Voice module): FF 09 STATUS_NAV_FAILED BB FF: Frame Header 09: Device Identifier (09 represents the voice module) STATUS_NAV_FAILED: Status content (indicating navigation failure) BB: Checksum.

[0022] The system achieves a complete closed loop from environmental perception and map building to accurate and safe autonomous navigation by using natural voice as the entry point, and provides a good user experience and system robustness through multimodal methods.

[0023] If certain terms are used in the specification and claims to refer to specific components, those skilled in the art will understand that hardware manufacturers may use different names to refer to the same component. This specification and claims do not distinguish components based on differences in name, but rather on differences in function. The term "comprising" as used throughout the specification and claims is an open-ended term and should be interpreted as "comprising but not limited to." "Approximately" means that within an acceptable margin of error, those skilled in the art can solve the technical problem and substantially achieve the technical effect within a certain margin of error.

[0024] It should be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes that element.

[0025] The foregoing description illustrates and describes several preferred embodiments of the present invention. However, as previously stated, it should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the inventive concept described herein through the foregoing teachings or techniques or knowledge in related fields. Any modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A voice navigation control method for a vehicle-mounted robot, characterized in that, The method uses voice as the human-computer interaction interface and includes the following steps: S1. Continuously monitor ambient audio and perform preprocessing, including noise reduction, dereverberation, pre-emphasis, and frame windowing; when a preset wake-up word is detected, send a wake-up signal to the main control unit via serial port and enter a command recognition window of fixed duration; S2. In the command recognition window, perform automatic speech recognition and natural language processing on the input speech, parse out the user intent and key entities, and classify the parsing results into mapping commands, motion control commands or navigation commands. S3. For the mapping command, start the SLAM module and drive the LiDAR, odometer and IMU sensor to collect data. Based on particle filtering and scan matching, perform incremental map construction in a loop. When the map quality judgment conditions are met, persist the map as a map file. S4. For navigation commands, the target name is parsed and the corresponding coordinates are queried from the location database. The static map is loaded through the navigation scheduling module and adaptive Monte Carlo positioning is performed. The global planner generates the global path, and the local planner generates real-time executable speed commands. These commands are then published to the chassis controller via the cmd_vel topic or serial port protocol. S5. During hardware execution, receive data from the motor encoder, odometer and IMU in real time, perform multi-sensor fusion and state estimation, and correct the execution deviation according to the closed-loop control strategy until the error between the actual state and the target state meets the preset tolerance or navigation failure is determined. S6. When recognition fails, navigation is obstructed, or an anomaly occurs, trigger corresponding feedback and recovery behaviors, including voice prompts, rotating in place, reversing slightly, clearing the cost map, and waiting for manual intervention. S7 provides feedback to users on key events through TTS voice broadcasting, RGB light strips, and buzzers in a multimodal manner.

2. The voice navigation control method for a vehicle-type robot according to claim 1, characterized in that: The wake-up word detection operates continuously in a low-power mode during the listening state. When a wake-up word is detected, a unique wake-up message is sent to the main control unit via the serial port, and a command recognition window of a fixed duration is opened after wake-up. The command recognition window is preferably 15 seconds.

3. The voice navigation control method for a vehicle-type robot according to claim 1, characterized in that: In S2, speech recognition is performed locally offline, recognizing a predefined set of limited instructions. When recognition is successful, a unique command identifier is sent to the main control unit via serial port. If recognition fails or times out, no command identifier is sent and the system automatically resets to standby listening state.

4. The voice navigation control method for a vehicle-type robot according to claim 1, characterized in that: In S3, the mapping process uses the gmappingSLAM algorithm based on particle filtering, which includes particle set initialization, motion model prediction, scan matching, weight calculation, resampling and map update steps; and monitors map quality in real time during operation, including particle weight distribution, scan matching score, number of loop closure detections and map coverage. When the map quality is lower than a preset threshold, the SLAM parameters are automatically adjusted.

5. The voice navigation control method for a vehicle-type robot according to claim 1, characterized in that: In S4, the navigation scheduling process is implemented based on the ROS navigation stack. It uses adaptive Monte Carlo positioning for real-time pose estimation, uses a global planner to generate a global path, uses a local planner to generate local velocity commands, and maintains global and local cost maps. When local planning fails, a predefined recovery behavior sequence is triggered, and after multiple unsuccessful recovery attempts, navigation failure is marked and the user is prompted via TTS voice.

6. The voice navigation control method for a vehicle-type robot according to claim 1, characterized in that: The state estimation employs multi-sensor fusion of odometry and IMU, implemented through Kalman filtering or the EKF or UKF algorithm from the robot_localization package. The fused odometry information is used to publish odom topics and serves as input for localization and closed-loop control. The closed-loop control calculates the deviation e, and the formula for calculating the deviation e is: e = target velocity / position - actual velocity / position; It generates corrections for the motor duty cycle or speed command using proportional, integral, and derivative terms until the error meets the preset accuracy.

7. The voice navigation control method for a vehicle-type robot according to claim 1, characterized in that: The system uses a standardized frame format in its communication protocol for issuing commands and providing status feedback. The frame format includes a frame header, device identifier, command or status type, parameter data, and verification, and is implemented using hexadecimal encoding. The multimodal feedback includes TTS voice broadcasting, RGB light bar color or mode switching, and buzzer frequency prompts, which are used to provide feedback on key statuses to the user.

8. A vehicle-mounted robot voice navigation control system based on any one of claims 1-7, characterized in that: include: The voice interaction module is used to collect ambient audio, perform wake word detection, automatic speech recognition and natural language understanding, and send a wake-up signal or command identifier to the central scheduling unit via serial port when wake-up or recognition is successful. The central scheduling unit is configured to run mapping and navigation scheduling logic based on the ROS platform. It can receive commands from the voice interaction module and call the SLAM module or navigation module according to the command type. It manages the location database, path planning, local or global cost map and recovery behavior logic. The underlying execution unit, including the motor driver, wheeled chassis, encoder and power management module, is used to respond to motion commands issued by the central scheduling unit and return odometer and status data; Sensor arrays, including lidar, odometers or motor encoders, IMUs, and temperature or voltage sensors, are used to provide real-time sensing data for SLAM, positioning, and closed-loop control. The communication interface is used to realize serial communication between the voice module and the central scheduling unit, as well as the transmission of control commands and status feedback between the central scheduling unit and the underlying execution unit. The system is also equipped with a TTS unit for voice broadcasting and an RViz interface for visual debugging.

9. A vehicle-mounted robot voice navigation control system according to claim 8, characterized in that: The voice interaction module includes automatic level control, noise suppression, and echo cancellation functions, and supports predefined command sets and wake-word detection using an offline ASR engine; the central scheduling unit is implemented on the ROS platform, running the gmappingSLAM algorithm, AMCL positioning, and move_base navigation stack; the underlying execution unit is equipped with closed-loop control capabilities, receiving speed commands based on an encoder and PID controller via cmd_vel or serial port protocol; the system supports persistently saving maps in map.pgm and map.yaml formats for subsequent navigation loading.

Images