A general automatic driving control system for indoor and outdoor mobile operation vehicles

Abstract

The application relates to the technical field of automatic driving control and discloses a general automatic driving control system for indoor and outdoor mobile operation vehicles, which comprises an upper intelligent computing module, a bottom driving execution module and a cloud collaborative service module. The upper intelligent computing module performs environment perception, positioning planning and operation logic management, and generates bottom control instructions matched with the current mobile operation platform in combination with the vehicle type, chassis parameters and implement parameters; the bottom driving execution module receives the instructions to drive the vehicle and operation actions, and generates a vehicle running state, which comprises a safety takeover unit independent of the upper layer and used for executing speed zero setting, braking keeping and operation load disconnection when an exception occurs; and the cloud collaborative service module receives the running state and issues task instructions. The application improves the general adaptation capability of the system to different hardware platforms and guarantees the bottom running safety of the vehicle when the main control is abnormal.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving control technology, specifically to a universal autonomous driving control system for indoor and outdoor mobile work vehicles. Background Technology

[0002] Currently, autonomous driving technology has been applied in mobile operations such as cleaning, inspection, and logistics. Existing autonomous driving control systems typically adopt a highly hardware-software integrated development approach, with upper-level navigation planning algorithms directly coupled to lower-level execution logic. When dealing with different vehicle types, chassis sizes, or different interface tools, it is necessary to rewrite the underlying driver code and kinematics calculation modules, resulting in insufficient universal adaptability of the system to different operating platforms and low software reusability.

[0003] The actual operating environment of mobile work vehicles often includes indoor-outdoor transition zones or areas obstructed by trees and buildings. Most existing vehicles rely on the Global Navigation Satellite System (GNSS) for absolute positioning. When the positioning signal switches from a valid state to a short-term failure state due to environmental obstruction, the positioning result may jump or be completely lost. Due to the lack of an effective multi-source sensing fusion compensation mechanism, vehicles struggle to maintain continuous positioning output in signal blind spots or transition areas, leading to deviations from the driving trajectory or abnormal interruptions to the work task.

[0004] Regarding system operational safety, the protection logic of existing control systems primarily relies on the upper-level master control equipment. The lower-level drive modules typically act as passive action response units, only responsible for executing instructions issued from the upper level. When abnormal situations occur during operation, such as software crashes in the upper-level computing module, operating system freezes, or communication links between upper and lower levels are interrupted, the lower-level drive modules, lacking takeover decision logic independent of the master control, will continue to maintain their pre-interruption state and continue driving or outputting load. This safety architecture, dependent on master control decisions, cannot directly cut off power in the event of communication failure or master control malfunction, leading to potential safety hazards related to vehicle loss of control. Summary of the Invention

[0005] The technical problem solved by this invention is that the existing mobile work vehicle automatic driving system lacks universal adaptability to different chassis hardware and work tools, has poor positioning continuity when switching between indoor and outdoor environments or in signal-blocked environments, and lacks low-level safety takeover capability independent of the main control mechanism when an anomaly occurs, which poses a risk of equipment loss of control and operational safety.

[0006] To address the above problems, the present invention provides the following technical solution:

[0007] This invention provides a universal automatic driving control system for indoor and outdoor mobile work vehicles, the control system comprising:

[0008] The upper-level intelligent computing module is used to perform environmental perception, map building, navigation and positioning, path planning and operation logic management, and generate underlying control commands that match the current mobile operation platform based on vehicle type, chassis parameters and operation equipment parameters.

[0009] The underlying drive execution module is used to receive the underlying control commands and drive the vehicle hardware to perform walking and other operational actions; the underlying drive execution module is also used to collect chassis drive feedback, actuator feedback and safety status signals, and generate vehicle operating status; the underlying drive execution module includes a safety takeover unit independent of the upper-level intelligent computing module, which is used to execute speed zeroing, brake holding and work load disconnection in the event of an anomaly, thereby enabling the vehicle to enter a safe output state;

[0010] The cloud-based collaborative service module is used to receive the vehicle's operating status, perform remote monitoring and task scheduling, generate cloud-based task instructions, and send the cloud-based task instructions to the upper-layer intelligent computing module.

[0011] Furthermore, the upper-layer intelligent computing module includes:

[0012] The power conversion unit is used to connect to the vehicle-side power supply and convert the vehicle-side power supply into multiple power supply voltages required by the system.

[0013] The sensor access unit is powered by the protected power supply branch of the multi-channel power supply voltage, and is used to collect multi-source sensing data generated by the real-time dynamic differential global navigation satellite system positioning module, binocular depth camera, lidar and IMU, and receive external time reference.

[0014] The network communication unit is powered by the protected power supply branch and is used to establish a two-way network communication link between the vehicle and the cloud collaborative service module, upload the vehicle's operating status, and receive cloud task instructions.

[0015] Furthermore, the upper-layer intelligent computing module deploys a robot operating system middleware, which includes:

[0016] Hardware access nodes are used to parse the multi-source sensing data and publish standardized topics in the system;

[0017] The task control node is used to receive the standardized topics and the cloud task instructions, and to execute the environmental perception, map building, navigation and positioning and path planning.

[0018] The chassis service node is used to monitor the motion planning route and convert it into the underlying control commands that match the underlying drive execution module.

[0019] Furthermore, the underlying driver execution module includes:

[0020] The bus communication unit is used to receive the underlying control commands and convert them into differential control bus frames or drive control messages, and send them to the underlying travel driver to complete the closed-loop speed control of the left and right drive motors of the vehicle, and obtain fault feedback information.

[0021] The relay control unit is used to receive the underlying control commands and convert them into switching signals to control the power enable, direction selection, start / stop status and safety power-off status of the work execution component, and to detect the contact feedback status.

[0022] Furthermore, the operation control node is used to perform the navigation and positioning, wherein the operation control node is used to:

[0023] Process inertial measurement unit data and image sequences to output local visual-inertial inference pose;

[0024] It is also used to lock the most recent valid global navigation satellite system absolute positioning attitude when the global navigation satellite system signal switches from an effective state to a short-term failure state;

[0025] The system integrates the absolute positioning pose of the global navigation satellite system with the visual-inertial inference pose to determine the globally optimal three-dimensional pose, and then maintains the continuous output of vehicle positioning results based on the globally optimal three-dimensional pose to complete the navigation and positioning.

[0026] Furthermore, the job control node is used to perform the environmental perception, map building, and path planning, wherein the job control node is used for:

[0027] Multi-source sensing data is uniformly projected onto a two-dimensional local grid and low-lying protruding obstacles are identified to generate a local cost map;

[0028] Based on the local cost map, the local trajectory cost is calculated using the time elastic band trajectory optimization cost formula;

[0029] The path planning is completed by optimizing discrete trajectory point configurations that reduce the cost of local trajectories using nonlinear graph optimization and outputting a motion planning route.

[0030] In the local cost map generation, the operation control node is used to mark the grid area as an obstacle-occupied state when the reflectance change gradient of the grid area exceeds a preset reflectance threshold; the reflectance threshold is a gray level pre-calibrated based on the reflectance difference between the surface material of the operation environment and the obstacle material.

[0031] Furthermore, the chassis service node is used to generate underlying control commands that match the current mobile work platform based on the vehicle type, chassis parameters, and work implement parameters, wherein the chassis service node is used to:

[0032] Extract the desired linear velocity and desired angular velocity of the chassis center from the system topic;

[0033] Based on the desired linear velocity and desired angular velocity of the chassis center, the differential inverse kinematics model corresponding to the vehicle type, and the wheelbase value determined by the chassis parameters, the target linear velocities on both sides are calculated.

[0034] The drive motor speed command is calculated based on the target linear velocities on both sides and the mechanical characteristic parameters of the underlying driver.

[0035] The drive motor speed command is encapsulated in the actuator action code mapped from the working tool parameters to generate the underlying control command.

[0036] Furthermore, the safety takeover unit within the underlying drive execution module is used to execute the speed zeroing, brake holding, and work load disconnection in the event of an anomaly, thereby enabling the vehicle to enter the safe output state. The safety takeover unit is used to:

[0037] Record the arrival time of the underlying control command data packets in two adjacent frames and calculate the command reception time deviation value;

[0038] The underlying control link health score is calculated based on the instruction reception time deviation value and the communication timeout threshold value.

[0039] When the health score of the underlying control link triggers the preset protection threshold, it is determined that an abnormality has occurred, and then the speed is set to zero, the braking is maintained and the work load is disconnected to enter the safe output state, and an abnormal interruption report is generated for uploading.

[0040] The communication timeout threshold is the maximum allowable time interval for determining the failure of the upper-layer communication link; the preset protection threshold is the condition triggered when the health score of the lower-layer control link is lower than a preset safety value.

[0041] Furthermore, the underlying drive execution module is used to receive the underlying control commands and drive the vehicle hardware to perform the walking and other operational actions. The underlying drive execution module includes an arbitration unit, which is used to:

[0042] Continuously monitor the input status of multiple control channels and extract the valid flags and preset control weights corresponding to each control channel;

[0043] Based on the valid flag and the preset control weight, the control channel with the highest priority value is determined as the current execution entity;

[0044] The corresponding underlying control instructions or manual instructions are obtained based on the current executing entity, and the vehicle hardware is driven to perform the corresponding walking and other operational actions.

[0045] Furthermore, the upper-layer intelligent computing module is used to execute the job logic management and support the teaching and learning mode, wherein the upper-layer intelligent computing module is used for:

[0046] Record the global optimal three-dimensional pose of the vehicle during its driving process and simultaneously read the corresponding switch signal status of the system;

[0047] The switch signal state and the globally optimal three-dimensional pose are bound together to form a structured teaching trajectory;

[0048] In subsequent operation phases, the structured teaching trajectory is invoked to reproduce the path in the target environment and trigger automatic operation actions, thereby completing the operation logic management.

[0049] This invention provides a universal automatic driving control system for indoor and outdoor mobile work vehicles. It has the following beneficial effects:

[0050] 1. This invention generates low-level control commands by combining vehicle type, chassis parameters, and work implement parameters through an upper-level intelligent computing module, and publishes standardized topics using robot operating system middleware, decoupling the upper-level planning algorithm from the low-level hardware execution logic. This solution enables the same control system to directly calculate and output drive commands matching different chassis sizes and work implement types without changing the main code structure, improving the system's universal adaptability to multiple mobile work platforms.

[0051] 2. The operation control node of this invention adopts a multi-source positioning data fusion processing mechanism. When the global navigation satellite system signal switches from an effective state to a short-term failure state due to environmental obstruction, the system locks the most recent effective absolute positioning pose and fuses it with the visual-inertial inference pose to determine the three-dimensional pose. This mechanism enables the vehicle to maintain continuous output of positioning results when experiencing changes in indoor and outdoor environments or passing through obstructed areas, avoiding operation interruptions caused by the loss of positioning signals.

[0052] 3. The underlying drive execution module of this invention is configured with a safety takeover unit independent of the upper-layer intelligent computing module. This unit calculates the health score of the underlying control link by recording the instruction reception time deviation value. When the upper-layer algorithm crashes or communication times out, causing the health score to trigger a preset protection threshold, the underlying module directly bypasses the upper-layer instruction execution speed zeroing, braking hold, and load disconnection actions, providing direct intervention capability based on the underlying hardware when the main control system malfunctions, reducing the safety hazard of vehicle runaway. Attached Figure Description

[0053] Figure 1 This is a diagram of the control system architecture of the present invention;

[0054] Figure 2 This is a flowchart illustrating the overall workflow of the present invention;

[0055] Figure 3 This is a diagram of a multi-source sensing data processing and synchronization architecture provided in one embodiment of the present invention;

[0056] Figure 4 This is a cloud-based task collaborative scheduling and path generation architecture diagram provided in one embodiment of the present invention;

[0057] Figure 5 This is a diagram of an environmental perception state estimation and planning control architecture provided in one embodiment of the present invention;

[0058] Figure 6 This is a diagram of the underlying control calculation and physical drive closed-loop architecture provided in one embodiment of the present invention;

[0059] Figure 7 This is a diagram of a vehicle operation status monitoring and safety feedback arbitration architecture provided in one embodiment of the present invention;

[0060] Figure 8 This is a scatter bubble chart showing the distribution of movement error and obstacle avoidance distance of the self-propelled work platform in multiple scenarios according to the present invention. Detailed Implementation

[0061] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] See attached document Figure 1This invention provides a universal automatic driving control system for indoor and outdoor mobile work vehicles. This control system can be packaged as an integrated automatic driving control box or control assembly, and is adaptable to different types of mobile work platforms such as orchard transport vehicles, spraying vehicles, lawn mowers, factory inspection vehicles, and factory transport vehicles.

[0063] The control system includes an upper-level intelligent computing module, an lower-level drive execution module, and a cloud-based collaborative service module.

[0064] The upper-layer intelligent computing module is used to perform environmental perception, Simultaneous Localization and Mapping (SLAM), navigation and positioning, path recording, path reproduction, path planning, obstacle recognition, obstacle avoidance decision-making, operation logic management, and data communication with mobile applications, web clients, or cloud platforms. The upper-layer intelligent computing module is also used to generate lower-level control commands that match the current mobile operation platform based on vehicle type, chassis parameters, and equipment parameters.

[0065] The underlying drive execution module receives control commands from the lower level and drives the vehicle hardware to perform actions such as walking, starting and stopping, steering, braking, lifting, venting, lighting, warning, and other operational actions. The underlying drive execution module also collects chassis drive feedback, actuator feedback, and safety status signals, and generates the vehicle's operating status.

[0066] The underlying drive execution module is configured with safety takeover logic independent of the upper-level intelligent computing module. When communication timeout, upper-level control anomaly, emergency stop triggering, or abnormal workload occurs, the underlying drive execution module can execute speed zeroing, brake holding, and workload disconnection, thereby enabling the vehicle to enter a safe output state.

[0067] The cloud-based collaborative service module receives vehicle operating status and performs remote monitoring, task scheduling, log management, video viewing, and software updates. It also generates cloud-based task instructions and distributes them to the upper-layer intelligent computing module. Remote control instructions issued by the cloud-based collaborative service module are used for task scheduling and remote monitoring; basic vehicle safety parking and underlying failure protection are handled locally by the underlying driver execution module.

[0068] As a preferred implementation, the upper-layer intelligent computing module adopts the NVIDIA Jetson Orin NX series embedded intelligent computing platform and can be configured to normal power consumption mode or Super power consumption mode according to the sensing algorithm load, heat dissipation capacity, and vehicle power supply capacity. The lower-layer driver execution module adopts an STM32 lower-layer driver board or a C30D lower-layer control board. The upper-layer intelligent computing module and the lower-layer driver execution module work together through a Universal Serial Bus (USB), serial port, RS-485 compliant communication link, Controller Area Network (CAN), or Ethernet communication link to form a hierarchical control structure that coordinates high-level intelligent decision-making with low-level safety execution.

[0069] The upper-layer intelligent computing module is primarily responsible for environmental perception, map building, path planning, and task management; the lower-layer driver execution module is primarily responsible for motor control, relay control, braking control, emergency stop monitoring, communication heartbeat monitoring, and safety zeroing control. When the upper-layer intelligent computing module experiences process abnormalities, communication interruptions, or power supply failures, the lower-layer driver execution module can maintain safe output based on local safety policies or switch to a preset safe output state.

[0070] In terms of hardware physical architecture, the general-purpose automatic driving control system for indoor and outdoor mobile work vehicles adopts a modular control box structure. The internal layout of the control box is divided into a computing control area, a power drive area, a power protection area, a communication area, and a sensor interface area; in other embodiments, it can also be arranged in layers according to the sensor layer, control layer, power layer, and power execution layer.

[0071] The computing and control area is used to house the Jetson intelligent computing platform, Universal Serial Bus Hub (USB-HUB), storage units, network communication modules, and the Robot Operating System 2 (ROS 2) operating environment. The power drive area is used to house the STM32 low-level driver board, relay modules, motor drive interfaces, brake control interfaces, wiper motor control modules, or other actuator control modules. The power protection area is used to house DC-DC power conversion modules, fuses, surge suppression devices, reverse connection protection devices, overcurrent protection devices, undervoltage detection circuits, contactors, or solid-state switches. The communication area is used to house Fourth Generation Mobile Communication (4G) communication modules, Wi-Fi communication modules, Real-Time Kinematic Global Navigation Satellite System (RTK-GNSS) antennas, 4G antennas, Wi-Fi antennas, router antennas, and remote communication links. The sensor interface area is used to connect binocular cameras, LiDAR, RTK-GNSS positioning modules, inertial measurement units (IMUs), rear sensors, surround-view sensors, or other environmental sensing devices.

[0072] Electrical isolation between the computing control area and the power drive area is achieved through shielded wiring harnesses, isolated communication interfaces, or isolated power supply modules. The output terminals of inductive loads in the power drive area are equipped with freewheeling, surge absorption, or transient suppression devices to reduce electromagnetic interference to the upper-level intelligent computing module and sensor signals during motor, relay, brake, and load switching.

[0073] The control box is equipped with standardized wiring terminals. These standardized terminals include at least the vehicle power input terminal, protected power output terminal, communication terminal, relay output terminal, motor drive control terminal, drive feedback terminal, brake control terminal, emergency stop input terminal, remote control takeover input terminal, and sensor interface terminal. Through these terminals, the control box can be connected to different chassis, different work implements, and different sensor combinations.

[0074] The control box is also equipped with fuse protection, overcurrent protection, undervoltage protection, reverse connection protection, status indication, fault indication, and maintenance and repair interfaces. The high-voltage power circuit and the low-voltage data signal circuit adopt a zoned layout, isolated transmission, shielded grounding, and terminal mis-insertion prevention design to suppress electromagnetic interference and improve the system's anti-interference capability, on-site maintenance efficiency, and fail-safe capability.

[0075] The control box, either internally or in conjunction with the upper-level intelligent computing module, is equipped with a power conversion unit. This unit connects to the vehicle-side power supply and generates the protected supply voltage required by the system. As one implementation, the control box can connect to a 12V, 24V, or 48V vehicle-side DC power supply. The power conversion unit converts the vehicle-side power supply into multiple supply voltages required by the system through fuse protection, reverse connection protection, surge suppression, undervoltage detection, and DC-DC conversion.

[0076] The Jetson intelligent computing platform, network communication module, sensors, relay drive circuits, and some actuator control circuits are powered by mutually isolated or mutually current-limited power supply branches. As a preferred approach, the power conversion unit forms a standard 12V DC bus and further generates 5V, 9V, 19V, 24V, or 48V power supply branches according to specific equipment requirements. For motors, brakes, lifting mechanisms, and other high-power operating components, their power supply can be provided by the vehicle-side power supply or an independent power branch; the upper-level intelligent computing module only outputs control signals or enable signals, thus avoiding directly superimposing the entire actuator load onto the 12V control bus.

[0077] The sensor access unit is powered by a protected power supply branch and acquires multi-source sensing data generated by the real-time dynamic differential global navigation satellite system positioning module (RTK-GNSS positioning module, binocular depth camera, LiDAR, and IMU) via USB, Ethernet, serial, CAN, or standard sensor terminals. The IMU can function as a standalone inertial measurement unit or be integrated into the RTK-GNSS positioning module, LiDAR module, or binocular depth camera module to provide vehicle attitude, angular velocity, and acceleration information.

[0078] The sensor access unit can also be configured with a time synchronization input, a synchronization signal distribution terminal, a shielded grounding terminal, and a sensor status detection terminal. The time synchronization input is used to receive the Pulse Per Second (PPS) signal output from the RTK-GNSS positioning module, IEEE 1588 Precision Time Protocol (PTP) time information, or other external time references. The sensor access unit transmits the time synchronization status, sensor online status, and data validity flags to the hardware access node, thereby forming a multi-source data link covering environmental perception, attitude estimation, and high-precision positioning.

[0079] The network communication unit is powered by a protected power branch generated by the power conversion unit and establishes a communication link between the vehicle and mobile applications, web clients, and cloud-based collaborative service modules via 4G, Wi-Fi, or wired networks. In one implementation, the network communication unit can be powered by a standard 12V DC bus; in other implementations, it can be powered by 5V, 9V, 12V, or other protected power branches, depending on the input specifications of the communication module or router.

[0080] The network communication unit is used to upload vehicle status, location, fault codes, task progress, log information, video streams and sensor summary data, and to receive work area, mapping instructions, route management instructions, task execution instructions, remote start / stop instructions, return instructions, pause instructions, continue operation instructions and over-the-air (OTA) update instructions issued by the mobile application terminal, web client or cloud collaborative service module 30.

[0081] The underlying drive execution module includes a relay control unit and a bus communication unit. The relay control unit preferably includes a multi-channel relay module, a solid-state switch module, or an isolated drive module. The relay control unit receives underlying control commands and converts them into switching signals to control the power enable, direction selection, start / stop status, and safety power-off status of the lifting motor, damper motor, starter motor, throttle actuator, brake actuator, lighting, warning lights, status lights, light sources, and other operating components.

[0082] The output of the relay control unit can be equipped with a freewheeling diode, transient voltage suppressor, opto-isolator, drive current detection circuit, or contact status feedback circuit to suppress the back electromotive force generated when the inductive load is disconnected and to detect the relay's energized state. Output channels involving braking, emergency stop, or safety-related work loads preferably employ a safety-state configuration of power-off disconnection or power-off braking.

[0083] The bus communication unit receives low-level control commands and converts them into differential control bus frames according to RS-485, CAN, serial port, or other industrial communication protocols. These differential control bus frames are then sent to the low-level drive driver to perform closed-loop speed control of the vehicle's left and right drive motors. The bus communication unit also acquires real-time speed, position, current, bus voltage, temperature, and fault feedback information from brushed motors, brushless motors, hub motors, track motors, servo drivers, or other drive mechanisms.

[0084] The cloud-based collaborative service module deploys message queue telemetry transmission services, real-time audio and video streaming services, interface services based on WebSocket and HyperText Transfer Protocol (HTTP), task scheduling services, caching services, time-series database services, and over-the-air (OTA) update services. It establishes a bidirectional data stream with the vehicle via a network communication unit. The message queue telemetry transmission service is used to issue cloud-based task commands, remote control commands, and security degradation commands. The real-time audio and video streaming service is used to transmit video streams, vehicle operating status, and on-site operation footage. The interface services based on WebSocket and HTTP protocols support route management, task management, equipment control, login authentication, system settings, log management, and status monitoring for mobile applications and web clients. The OTA update service is used to send software update packages, firmware update packages, or configuration parameters to the upper-layer intelligent computing module or the lower-layer driver execution module.

[0085] Among them, the security degradation instructions issued by the cloud-based collaborative service module are used for remote monitoring and task intervention. When network communication is abnormal, cloud instructions are delayed, or cloud services are unavailable, the vehicle's communication timeout protection, emergency stop response, brake holding, and work load disconnection are completed independently locally by the underlying drive execution module.

[0086] The upper-layer intelligent computing module deploys the robot operating system middleware. The robot operating system middleware is logically divided into hardware access nodes, chassis service nodes, and operation control nodes.

[0087] Hardware access nodes are used to parse data from binocular cameras, LiDAR, RTK-GNSS positioning modules, IMU, chassis serial communication, and actuator feedback, and publish standardized topics within the system. Job control nodes are used to perform autonomous mapping, map management, positioning fusion, path recording, path reproduction, task planning, automatic obstacle avoidance, and local path planning. They also receive standardized topics and task instructions from mobile applications, web clients, or cloud-based collaborative service modules, generating motion planning routes. Chassis service nodes monitor motion planning routes, speed control topics, or job action instructions, converting them into underlying control instructions that match the underlying driver execution modules.

[0088] As a preferred approach, the operation control node can implement path tracking and obstacle avoidance planning based on the ROS 2 Navigation 2 framework, and select DWB, MPPI, Regulated Pure Pursuit, or other ROS 2 local controllers according to vehicle kinematic constraints, sensor reliability, and operational environment complexity. When time-flexible constraint optimization is required, the operation control node can also implement TEB-type trajectory optimization strategies through adapter plugins or self-developed local planners to balance path tracking smoothness, obstacle avoidance, and chassis motion constraints.

[0089] See attached document Figure 2 This invention provides a universal automatic driving control method for indoor and outdoor mobile work vehicles, comprising the following steps:

[0090] S1, System initialization, hardware access nodes complete self-start verification, acquire multi-source sensing data and register and publish standardized topics;

[0091] S2, Cloud Task Issuance: The cloud collaboration service module issues cloud task instructions to the job control node;

[0092] S3, Environmental Perception and Planning: The operation control node generates a local cost map based on standardized topics and cloud task instructions, and calculates and generates a motion planning route.

[0093] S4, the underlying drive control, the chassis service node converts the motion planning route into underlying control commands and sends them to the underlying drive execution module. The underlying drive execution module controls the underlying travel drive and the work execution components and generates the vehicle's operating status.

[0094] S5, safety feedback protection: the underlying drive execution module monitors the vehicle's operating status. When it determines that the vehicle's operating status is abnormal, it executes independent takeover logic, causing the underlying travel drive to enter a state of zero speed, brake holding, or drive enable cut-off, and generates an abnormal interruption report. When the network communication link is available, the abnormal interruption report is uploaded to the cloud collaborative service module. When the network communication link is unavailable, the abnormal interruption report is cached locally and uploaded after the network is restored.

[0095] The implementation details of each module and its corresponding steps within the control system will be elaborated in the following sections.

[0096] See attached document Figure 3 The general autonomous driving control method for indoor and outdoor mobile work vehicles provided by the present invention includes the following sub-steps in the system initialization and multi-source perception data acquisition step S1.

[0097] S101, the hardware access node completes self-start verification and performs sensor timestamp synchronization calibration.

[0098] In this embodiment, after the upper-layer intelligent computing module is powered on, the hardware access nodes deployed within it send status query commands to various peripherals within the system via the sensor access unit to verify the bus communication status and the online status of each sensing hardware device. The sensing hardware devices may include RTK-GNSS positioning modules, binocular depth cameras, LiDAR, IMUs, and other environmental sensing devices.

[0099] For time alignment of multi-source sensing data, this embodiment employs a synchronization mechanism combining hardware synchronization reference and software compensation. As a preferred approach, the PPS signal output by the RTK-GNSS positioning module, the IEEE 1588 PTP time synchronization signal, or the valid time synchronization information output by the LiDAR is used as the system's primary time reference. This time synchronization information is isolated, shaped, and distributed via a time synchronization allocation unit, a low-level driver execution module, or a sensor access unit, enabling the binocular depth camera, LiDAR, IMU, and upper-level intelligent computing module to obtain timestamp information under the same time reference.

[0100] When some sensors do not support external PPS trigger input, the hardware access node reads the internal timestamp, synchronization flag, or host reception time from the sensor's data frame and performs time alignment using a software compensation algorithm. When the IMU is integrated into a binocular depth camera, RTK-GNSS positioning module, or LiDAR, the hardware access node obtains the IMU timestamp through the synchronization flag of the data frame output by the corresponding device and incorporates the IMU timestamp into a unified time reference.

[0101] Because data from different peripherals is affected by physical link baud rate, driver cache, internal device processing load, and operating system scheduling latency when it reaches the upper-layer intelligent computing module, the host reception time usually cannot directly represent the actual environmental acquisition time. If the above time deviations are not compensated for, visual image features, laser point clouds, and inertial data are prone to misalignment during spatial mapping when the vehicle is in motion.

[0102] Based on this, a software compensation algorithm is introduced for the hardware access node. Specifically, the hardware access node calculates the estimated acquisition time of the corresponding data frame based on the host's data reception time, link transmission delay, internal device processing delay, and clock skew. The link transmission delay, internal device processing delay, and clock skew can be estimated using the IEEE 1588 time protocol, device timestamps, driver layer timestamps, periodic request measurements, or sliding window filtering. The specific implementation of the aforementioned delay measurement and clock skew estimation can be achieved by those skilled in the art using conventional time synchronization measurement algorithms, which are well-known technologies in the field and will not be elaborated upon here.

[0103] The hardware access node uses the calculated estimated acquisition time to replace or correct the system's default assigned receiving timestamp, thereby aligning multi-source sensing data under the same time reference.

[0104] As a preferred safety design, to avoid synchronization logic deadlock caused by loose hardware wiring, synchronization source failure, or signal interference, the hardware access node continuously monitors the PPS signal, PTP synchronization status, and sensor data frame synchronization flag. When the hardware access node fails to detect the PPS signal for a continuous preset time, or detects an invalid PTP synchronization status or an abnormal sensor data frame synchronization flag, the system executes a time degradation strategy. The preset time can be set according to the sensor frame rate and control cycle; in this embodiment, the preset time can be set to 2 seconds.

[0105] In time-degraded mode, the hardware access node reads the local system time of the upper-layer intelligent computing module, or the most recent valid synchronization time, as the degradation timestamp. Simultaneously, the hardware access node appends a time synchronization failure flag, a synchronization source type flag, and a timestamp confidence flag to the header frame of the multi-source sensing data to prompt subsequent fusion positioning algorithms to lower the trust weight of data from that period. Once the synchronization source stabilizes, the hardware access node restores a unified time reference through smooth correction to avoid abrupt changes in positioning results caused by sudden timestamp mutations.

[0106] S102, the hardware access node parses the data protocol and registers and publishes standardized topics.

[0107] After acquiring the aligned multi-source sensing data, the hardware access node performs protocol unpacking operations on the data streams of different physical interfaces. Specifically, the hardware access node reads the National Marine Electronics Association 0183 (NMEA 0183) standard messages or Real-Time Kinematic (RTK) positioning messages output by the RTK-GNSS positioning module via the USB or serial interface of the sensor access unit, and extracts latitude, longitude, elevation, positioning quality factor, differential status, and global coordinate information from them.

[0108] The hardware access node also receives User Datagram Protocol (UDP) packets sent by the LiDAR via the Ethernet interface of the sensor access unit, and decodes the UDP packets into a discrete point cloud containing three-dimensional spatial coordinates, scan timestamps, and reflectivity intensity. The hardware access node also acquires forward-facing field-of-view images, depth images, or binocular visual features via a binocular depth camera, and obtains attitude, angular velocity, and acceleration data via a standalone IMU or the sensor's built-in IMU.

[0109] After data parsing, the hardware access node converts the heterogeneous data into a standard ROS 2 message structure within the robot operating system middleware, i.e., the communication architecture of the ROS 2 environment. In this embodiment, the discrete point cloud is encapsulated as a sensor_msgs / PointCloud2 point cloud message; the image matrix is ​​encapsulated as a sensor_msgs / Image image message; and the localization quality factor and coordinate data are encapsulated as a sensor_msgs / NavSatFix navigation and localization message.

[0110] The aforementioned message structure is mapped to preset network topic names and continuously published as standardized topics after being registered within the operating system. These standardized topics serve as a unified data source interface broadcast throughout the system network, allowing job control nodes and other subsequent control components to subscribe and invoke them. Consequently, underlying hardware data can be transmitted to upper-layer algorithms in a unified message format, providing a data foundation for subsequent positioning fusion, environmental modeling, path planning, and chassis control.

[0111] See attached document Figure 4 In the general autonomous driving control method for indoor and outdoor mobile work vehicles provided by the present invention, the cloud task distribution step S2 includes the following sub-steps.

[0112] S201 establishes a bidirectional network communication link and maintains the device heartbeat.

[0113] In this embodiment, the network communication unit is equipped with a cellular network communication module. After power-on, the cellular network communication module connects to the wide area network and establishes a transmission control protocol connection with the Message Queuing Telemetry Transport (MQTT) service deployed in the cloud collaborative service module.

[0114] To ensure the link status can be recognized by the cloud-based collaborative service module and the vehicle's local control system, the operation control node reports the vehicle's operating status to the cloud-based collaborative service module via the network communication unit at a preset frequency. As a preferred method, the preset frequency is 1Hz. The vehicle's operating status includes the current local coordinates of the chassis, remaining battery power, online markers of multi-source sensors, and fault codes from the underlying drive system and operation execution components.

[0115] To ensure the continuity of communication and avoid vehicle safety status relying on remote network links, a network status daemon runs internally within the network communication unit. This daemon monitors network connection status, cloud handshake heartbeat packets, and message transmission and reception status. When the network communication unit detects that handshake heartbeat packets with the cloud collaborative service module have been lost consecutively beyond a preset timeout number, the network communication unit writes a network interruption fault code to the vehicle's operating status and feeds this vehicle operating status back to the operation control node for local caching.

[0116] During a network outage, the vehicle enters either a local autonomous hold, local pause, stationary stop, return to base, or await manual takeover state, depending on its current task status. Safety actions involving emergency stops, brake holding, and disconnection of the workload are executed locally by the underlying drive execution module, without relying on real-time feedback from the cloud-based collaborative service module. After the network is restored, the vehicle's operating status, fault codes, task progress, and log information cached during the outage are resumed via the network communication unit.

[0117] S202 receives and parses cloud task instructions to generate a reference path sequence adapted to the local coordinate frame.

[0118] In this embodiment, the cloud-based collaborative service module sends cloud-based task instructions to the network communication unit based on a background timed triggering mechanism, mobile application operations, web client task configuration, or manual scheduling operations. These cloud-based task instructions may include work area boundaries, GNSS-defined areas, mapping start instructions, route planning instructions, route reproduction instructions, stopping points, work time, start / stop control instructions, return instructions, and actuator action codes bound to waypoints or work phases.

[0119] Once the vehicle receives the GNSS-defined area or the boundary of the work area, the work control node can trigger an autonomous exploratory mapping process and generate an environmental map after mapping is completed. The environmental map is used for subsequent path recording, path reproduction, and automatic job invocation.

[0120] At the data structure level, cloud-based task instructions can be encapsulated using JavaScript Object Notation (JSON) format. As an implementation, the internal fields of a cloud-based task instruction include a globally unique identifier, a target trackpoint array, and a task execution action code. The target trackpoint array consists of latitude and longitude coordinates in the World Geodetic System 1984 (WGS84). The task execution action code is bound to the target trackpoint or task stage and is used to indicate actions such as takeoff and landing, start / stop, spraying, mowing, lighting, warning, or other tasks. After receiving this data packet, the network communication unit transmits it transparently to the task control node within the upper-layer intelligent computing module.

[0121] To enhance mission safety, the operation control node performs a mission validity check after receiving mission instructions from the cloud. As one implementation, the operation control node first transforms the first coordinate point in the target waypoint array and the vehicle's current location to the same local Cartesian coordinate system, then calculates the Euclidean distance between them to assess mission feasibility. When the Euclidean distance exceeds the preset safe tracking radius, the operation control node determines the mission is abnormal and sends a rejection message to the cloud-based collaborative service module via the network communication unit, thereby preventing the vehicle from being guided to a location outside the safe range.

[0122] Once the cloud-based task instructions pass the validity check, the job control node invokes a projection transformation algorithm to process the target waypoint array. As an implementation method, the projection transformation algorithm is based on the Universal Transverse Mercator (UTM) projection principle and, combined with the WGS84 reference ellipsoid parameters, converts spherical latitude and longitude coordinates into a set of planar coordinate points in a local Cartesian coordinate system. The local Cartesian coordinate system can use the vehicle's initial starting position, the mapping starting point, or a preset task origin as its coordinate origin.

[0123] Considering that a large physical span between adjacent target waypoints may lead to a lack of stable forward guidance references in the subsequent path tracking process, the operation control node densifies the set of planar coordinate points. Specifically, when the distance between adjacent planar coordinate points exceeds a preset physical threshold, the operation control node uses a linear interpolation algorithm to insert intermediate path points between the adjacent planar coordinate points. The preset physical threshold is determined based on the vehicle's local control cycle, the expected maximum travel speed, and the path tracking accuracy requirements; in this embodiment, the preset physical threshold is set to 2m.

[0124] The densed set of planar coordinate points, together with their associated job execution action codes, constitutes a structured global reference path. This global reference path is cached in the system memory of the upper-layer intelligent computing module and, in subsequent steps, is used in conjunction with the standardized topic to calculate and generate motion planning routes.

[0125] See attached document Figure 5 In the general automatic driving control method for indoor and outdoor mobile work vehicles provided by the present invention, the environmental perception and planning step S3 includes the following sub-steps.

[0126] S301, based on visual inertia and global constraints, performs downgraded fusion state estimation.

[0127] In this embodiment, the inertial measurement unit (IMU) data can be provided by a standalone IMU, or by an IMU integrated within a binocular depth camera, an RTK-GNSS positioning module, or a lidar system. The hardware access node times-aligns the IMU data, image frames, point cloud frames, and RTK-GNSS positioning data before sending them to the job control node, which then performs the fusion positioning calculation.

[0128] Specifically, the operation control node extracts corner features from the image sequence and performs inter-frame matching tracking using optical flow. Simultaneously, it performs pre-integration processing on the inertial measurement unit data within a time window. Subsequently, the operation control node uses a nonlinear optimization algorithm to determine the state variables that reduce the sum of the reprojection error and the pre-integration residual, thereby outputting the local visual inertial pose estimation. The feature extraction, optical flow tracking, pre-integration processing, and nonlinear optimization processes in visual inertial state estimation can be implemented using conventional visual inertial odometry methods, which are well-known techniques in the field and will not be elaborated upon here.

[0129] When the vehicle is in an open area and the positioning quality factor, differential state, and time synchronization state output by the RTK-GNSS positioning module meet the preset conditions, the operation control node synchronously extracts the absolute positioning pose of the global navigation satellite system contained in the standardized topic, and performs Kalman filtering fusion of the absolute positioning pose with the visual inertial inference pose to obtain the current pose of the vehicle.

[0130] Considering that mobile work vehicles may experience short-term signal obstruction or quality degradation when operating under tree canopies, in factory passageways, semi-indoor areas, or indoor-outdoor transition areas, the work control node introduces an adaptive degradation mechanism. When the GNAS signal switches from an effective state to a short-term failure state, the work control node locks the most recent GNAS absolute positioning pose that meets the quality requirements and uses the adaptive degradation fusion pose formula to calculate the globally optimal three-dimensional pose:

[0131] ;

[0132] in, Represents the globally optimal 3D pose; Indicates the pose calculated from visual inertia; This indicates the most recent valid global navigation satellite system absolute positioning attitude; This represents the initial confidence weight for absolute positioning, determined jointly by the positioning quality factor, differential state, and time synchronization state. This indicates the pose deviation between absolute positioning and local estimation; Indicates the signal decay time constant; Indicates the duration of satellite signal loss; This represents the degradation compensation coefficient that decreases as the signal loss time increases; This represents the dynamically weighted pose correction.

[0133] Through the above processing, during the short-term loss of satellite signals, the influence weight of the most recent absolute positioning data on the current pose gradually decreases over time, and the vehicle positioning result is mainly maintained by the visual inertial odometer for continuous output, thereby reducing the control disturbance caused by sudden positioning changes to the underlying drive execution module.

[0134] To avoid the continuous accumulation of local calculation errors, when the duration of satellite signal loss exceeds the preset degradation timeout threshold, or when the reprojection error, inertial residual, map matching residual, or time synchronization failure flag of the visual inertial odometry exceeds the preset threshold, the operation control node triggers the safety stop logic and interrupts the current task.

[0135] As one implementation method, the degradation timeout threshold can be set to 30 seconds, or it can be dynamically adjusted according to vehicle speed, complexity of the work area, sensor status, and safety boundaries. After the safe parking logic is triggered, the chassis service node sends a speed zeroing control intention to the underlying drive execution module, and the underlying drive execution module performs local brake holding and disconnects the work load.

[0136] S302, executes multi-dimensional trajectory point teaching records and actuator state collaborative binding.

[0137] To ensure that the reference path in the cloud-based task instructions possesses reproducible spatial and operational attributes, this embodiment employs a teaching-learning mode. In this mode, the operator guides the vehicle along the target area using a multi-channel remote controller. During vehicle movement, the operation control node records the globally optimal 3D pose output in real-time by S301 at a preset frequency. As a preferred method, the preset frequency is 10Hz.

[0138] Within the same clock cycle of recording the pose, the job control node synchronously reads the status of the switching signals received by the relay control unit. These switching signals characterize the operating mode of the work execution components, such as cutter head start / stop, damper opening / closing, spray start / stop, lifting status, or lighting status. The job control node binds the operating mode characteristics to the current globally optimal 3D pose, forming a multi-dimensional feature set.

[0139] As the vehicle continues to move, multiple multi-dimensional feature groups arranged in chronological order constitute a structured teaching trajectory. The structured teaching trajectory contains both spatial coordinate information and operational action coordination information, and can be uploaded to the cloud collaborative service module via the network communication unit, serving as a sample data source for subsequent generation or issuance of cloud task instructions.

[0140] During subsequent automated operations, the operation control node invokes the structured teaching trajectory to reproduce the execution path. Specifically, the operation control node performs a closed-loop comparison between the real-time fused positioning pose and the target pose in the structured teaching trajectory, and dynamically corrects the motion planning route based on the deviation between the two. At the same time, it invokes the bound operation execution action code according to the corresponding trajectory point or operation stage.

[0141] As a preferred approach, under operating conditions where the sensors have completed internal and external parameter calibration, time synchronization is effective, ground adhesion is stable, the chassis exhibits no significant lateral slippage, vehicle speed is within a preset low-speed range, and the reference path length is within a preset test range, the path recording and path reproduction module can achieve centimeter-level trajectory reproduction accuracy. For example, under prototype testing conditions, the trajectory reproduction error can be less than 5cm.

[0142] In conditions such as grasslands, mud, orchards, slopes, slippery surfaces, or the presence of irregular obstacles, the system sets corresponding engineering judgment thresholds based on vehicle speed, chassis size, sensor confidence, and safety boundaries, and prioritizes obstacle avoidance safety and vehicle attitude stability through local replanning or deceleration strategies.

[0143] S303 uses multi-sensor fusion to construct a local cost map and identify low-lying obstacles.

[0144] In addition to estimating the vehicle's own state, the operation control node also performs perception modeling of the vehicle's surrounding environment, generating a local cost map based on standardized topics and cloud-based task instructions. Specifically, the operation control node invokes a coordinate transformation algorithm to project the LiDAR point cloud data from the standardized topics and the depth images from the binocular depth cameras onto a two-dimensional local grid. This two-dimensional local grid is established centered on the vehicle's globally optimal 3D pose and is updated as the vehicle moves.

[0145] To identify low-lying obstacles commonly found in agricultural, orchard, storage, or factory environments, the operation control node analyzes the spatial geometric height difference of the point cloud, and combines binocular depth images, continuous frame depth abrupt change features, and echo reflectivity intensity features of the laser point cloud to identify low-lying protruding obstacles within the sensor's effective field of view and effective detection distance.

[0146] As a preferred approach, when the target reflectivity, illumination conditions, point cloud density, depth map validity, and sensor installation angle meet preset conditions, the system can mark the occupancy of obstacles with a height of not less than 5 cm. With sufficient coverage from the vehicle's forward or circumferential sensors, the system can construct a local cost map within a preset distance in front of or around the vehicle. The preset distance can be set according to the sensor range, vehicle speed, and braking distance; in this embodiment, the preset distance can be set to 40 m.

[0147] When the height difference of a point cloud or depth image within a certain grid area exceeds 0.05m, or the reflectance gradient of that grid area exceeds a preset reflectance threshold, or stable non-ground protrusion features appear in consecutive frames, the operation control node marks that grid area as an obstacle-occupied state. The reflectance threshold can be determined by pre-calibrating the reflectance difference between the surface material and the obstacle material in the current operating environment. As one implementation method, the reflectance threshold can be set to 30 to 50 dimensionless gray levels within the range of 0 to 255.

[0148] For areas behind, to the sides of the vehicle, or areas obstructed by sensors, collaborative detection can be performed using rear-view sensors, surround-view sensors, supplementary LiDAR, ultrasonic sensors, millimeter-wave radar, or chassis safety boundary models. When blind spot data is insufficient to support passage determination, the operation control node prioritizes triggering deceleration, stopping, or requesting manual intervention.

[0149] After the occupancy markers are completed, the operation control node performs a two-dimensional outward expansion calculation on the obstacle occupancy grid based on the actual physical contour dimensions of the vehicle chassis, positioning error, braking distance, and the extension range of the operation execution components, thereby generating a local cost map for avoidance decisions.

[0150] S304, based on local constraints and closed-loop guided execution of motion planning path calculation.

[0151] After completing the local cost map construction, the job control node enters the local dynamic trajectory generation stage. To ensure smooth chassis movement while avoiding obstacles, the job control node can use the ROS 2 Navigation 2 framework to call Dynamic Window Based (DWB), Model Predictive Path Integral (MPPI), Regulated Pure Pursuit, or other local controllers to generate speed control commands. In scenarios that require the introduction of time elastic constraints, the job control node can also implement Timed Elastic Band (TEB) type trajectory optimization strategies through adapter plugins or self-developed local planners.

[0152] Among them, the TEB-type trajectory optimization strategy is used to jointly optimize local paths in both spatial and temporal dimensions; the dynamic window-type local planning strategy is used to select feasible speed commands in the velocity space based on obstacle distance, vehicle kinematic constraints, and target direction. The operation control node can switch between different local replanning strategies based on the current environmental complexity, chassis motion constraints, sensor reliability, and processor load.

[0153] When employing a TEB-type trajectory optimization strategy, the operation control node represents the vehicle's local path as a discrete trajectory sequence subject to multiple constraints. A time difference interval is introduced between the discrete trajectory points as an optimization variable, ensuring the path satisfies comprehensive constraints in both spatial and temporal dimensions. The operation control node samples and generates a sequence of local discrete trajectory points in front of the vehicle and calculates the local trajectory cost using a time-elastic band trajectory optimization cost formula.

[0154] ;

[0155] in, Represents the value of a local trajectory; This represents the total number of local discrete trajectory points; Indicates the weight of the time penalty; Indicates the time interval between adjacent trajectory points; Represents the time cost term; Indicates obstacle avoidance weight; Indicates the first The pose of a discrete trajectory point; This represents the distance penalty function from the pose to the obstacle; Indicates the value of the obstacle; Indicates the kinematic constraint weights; Indicates the first Velocity vectors of discrete trajectory points; The kinematic penalty function represents velocity and acceleration; It represents the kinematic value.

[0156] The weight parameters in the aforementioned cost function can be configured based on the vehicle's maximum speed, maximum angular velocity, minimum turning radius, braking distance, the extension range of the work execution components, and the confidence level of the local cost map. If the current local planner uses DWB, MPPI, or other controllers, the work control node can use an evaluation function or cost function that matches the corresponding controller, and is not limited to the aforementioned time-elastic band trajectory optimization cost formula.

[0157] When the operation control node adopts a TEB-type trajectory optimization strategy, it combines the kinematic boundary conditions of the underlying walking drive, such as the maximum angular velocity, maximum linear velocity, minimum turning radius, wheelbase, or track width, and uses a nonlinear graph optimization library to solve for trajectory point configuration combinations that reduce the cost of the aforementioned local trajectories. The specific solution process for the nonlinear graph optimization library can be implemented by those skilled in the art using Ceres Solver, g2o, or other nonlinear optimization tools; these are well-known techniques in the field and will not be elaborated upon here.

[0158] When the job control node uses DWB, MPPI, Regulated Pure Pursuit, or other local controllers, it generates speed control commands based on the corresponding controller's speed sampling, trajectory evaluation, or tracking control mechanism. After planning is complete, the job control node extracts a smooth geometric path or speed control sequence and realigns it with the action codes of the job execution components bound along the path, ultimately outputting the motion planning route.

[0159] The motion planning route includes local spatial displacement constraints, velocity control constraints, and timing action commands from the underlying actuators, which are listened to and received by the chassis service node. In actual operation, when the graph optimization solution diverges, the local controller fails to generate effective velocity commands, or all candidate trajectories are determined to be obstructed, the operation control node outputs a zero-velocity control intention to the chassis service node to reduce the risk of collision.

[0160] See attached document Figure 6 In the general automatic driving control method for indoor and outdoor mobile work vehicles provided by the present invention, the underlying drive control step S4 includes the following sub-steps.

[0161] S401 performs the inverse kinematics solution of the motion planning route and completes the mapping of drive control messages.

[0162] In this embodiment, the chassis service node deployed inside the upper-layer intelligent computing module continuously listens to the motion planning route issued by the job control node. The chassis service node extracts the local target pose and velocity vector corresponding to the current timestamp from the motion planning route, or reads linear and angular velocity control instructions in cmd_vel format from the ROS 2 velocity control topic.

[0163] The chassis service node projects the aforementioned speed control information onto the chassis coordinate system and decomposes it to obtain the desired linear velocity and angular velocity of the chassis center. Subsequently, based on the current vehicle's chassis type, kinematic parameters, and communication message format, the chassis service node converts the speed control results into low-level control instructions adapted to the STM32 low-level driver board or C30D low-level control board.

[0164] When a vehicle adopts a physical configuration of two-wheel differential, four-wheel differential, or track differential, the chassis service node uses the differential inverse kinematics model to solve the motion requirements of the chassis center into left-side drive parameters and right-side drive parameters.

[0165] Specifically, the chassis service node uses the inverse kinematics formula to calculate the target linear velocity of the left drive wheel or left track, and the target linear velocity of the right drive wheel or right track:

[0166] ;

[0167] in, Indicates the target linear velocity of the left drive wheel or left track; Indicates the target linear velocity of the right drive wheel or right track; Indicates the desired linear velocity at the chassis center; This represents the desired angular velocity at the center of the chassis. Indicates the wheelbase or the center distance between the left and right tracks of a vehicle; This indicates the deviation in speed between the left and right sides caused by steering.

[0168] After calculating the target linear velocities on the left and right sides, the chassis service node, in conjunction with the drive wheel radius and mechanical reduction ratio coefficient corresponding to the underlying travel drive, converts the target linear velocities of the left and right drive wheels into drive motor speed commands. The chassis service node then encapsulates the drive motor speed commands, along with the operation execution action code corresponding to the current timestamp in the motion planning route, into underlying control commands.

[0169] As a preferred approach, the chassis service node performs limiting processing before encapsulating the underlying control commands. When the calculated linear velocity, angular velocity, or motor speed exceeds the rated operating range of the underlying drive, the chassis service node performs saturation cutoff according to the preset maximum physical limit to prevent the underlying drive from entering an overload state.

[0170] For Ackerman steering chassis, steering wheel chassis, omnidirectional wheel chassis, hydraulic drive chassis or other non-differential chassis, the chassis service node calls the kinematic model or parametric adaptation module that matches the corresponding chassis structure to convert the desired linear velocity and angular velocity of the chassis center into steering angle, wheel speed, hydraulic valve opening or servo control quantity.

[0171] The parameterized adaptation module includes at least chassis type identifier, wheelbase, track width, drive wheel radius, reduction ratio, maximum linear velocity, maximum angular velocity, maximum steering angle, control message format, feedback message format, and actuator action code mapping table. The chassis service node generates low-level control commands matching the target chassis based on these parameters. Thus, low-level driver adaptation for different mobile operation platforms is achieved without changing the upper-level path planning interface.

[0172] S402 parses the underlying control commands and enables the coordinated execution of the walking drive and the working components.

[0173] After receiving the underlying control command, the underlying drive execution module parses it using the bus communication unit and the relay control unit respectively. The bus communication unit extracts the speed control field from the underlying control command and converts it into a differential control bus frame or drive control message according to the RS-485 protocol, CAN protocol, serial port protocol, or other industrial communication protocol compatible with the underlying travel driver.

[0174] Differential control bus frames or drive control messages are sent to the underlying travel driver. Based on the received speed control field, the underlying travel driver drives the left and right motors of the vehicle through an internal closed-loop control algorithm, enabling the vehicle chassis to respond to the spatial motion constraints in the motion planning path.

[0175] While the walking drive is in operation, the relay control unit parses the operation execution action code in the underlying control instructions. Based on the logical state of the operation execution action code, the relay control unit controls the output state of its internal physical relays, solid-state switches, or isolated drive circuits. It then controls the power enable, direction selection, start state, stop state, and safety power-off state of the lifting motor, damper motor, starter motor, throttle actuator, brake actuator, lighting, warning lights, status lights, light sources, and other operation execution components through output level signals, enable signals, or direction control signals.

[0176] For safety-related operational components such as braking, emergency stopping, blade cutting, spraying, and lifting, the relay control unit preferably includes a feedback detection channel and fail-safe states. When the underlying drive execution module detects inconsistencies between the control output and feedback state, abnormal load current, relay sticking, or abnormal communication heartbeat, it prioritizes disconnecting the work load, maintaining the brakes, activating warning lights, or setting the speed to zero. Thus, while the vehicle is tracking its path, it can simultaneously perform lifting, mowing, spraying, lighting, warning, start / stop, and braking actions according to path points, work stages, or cloud-based task commands.

[0177] To form a closed-loop feedback loop at the bottom layer, the underlying drive execution module collects the current feedback, real-time speed, and relay engagement flags of the underlying drive unit in real time, and encapsulates them to generate the vehicle operating status according to a preset frequency. As a preferred method, the preset frequency is 5Hz. The vehicle operating status is transmitted back to the chassis service node via the bus to monitor the task execution progress and determine whether there is stalling, short circuit, drive overcurrent, relay sticking, or actuator feedback abnormality.

[0178] For the handshake communication of RS-485, CAN, serial port or other industrial communication protocols, as well as the low-level code implementation of relay drive logic, those skilled in the art can use standard industrial control driver programs, which are well-known technologies in the field and will not be described in detail here.

[0179] See attached document Figure 7 In the general automatic driving control method for indoor and outdoor mobile work vehicles provided by the present invention, the safety feedback protection step S5 includes the following sub-steps.

[0180] S501 performs underlying communication heartbeat monitoring and hardware-level independent takeover and zeroing logic.

[0181] In this embodiment, a real-time monitoring firmware is deployed within the underlying driver execution module. This firmware continuously polls the underlying control commands issued by the chassis service node via the bus communication unit using a hardware watchdog mechanism. Considering that the upper-layer intelligent computing module may experience process deadlocks, system restarts, communication link congestion, or power supply anomalies when performing heavy-load sensing tasks, the underlying driver execution module is configured with local security protection capabilities that do not rely on the upper-layer intelligent computing module or the cloud-based collaborative service module.

[0182] Local safety protection capabilities include low-level communication heartbeat monitoring, hardware emergency stop input detection, remote control takeover input detection, brake control, contactor or relay disconnection control, drive enable cutoff, speed zeroing output, and abnormal interruption report generation. Control outputs related to travel drive and safety-related operational loads are preferably set to a default safe state in the event of power failure.

[0183] Specifically, the underlying driver execution module records the arrival times of two adjacent frames of underlying control command data packets using a high-precision timer and calculates the command reception time deviation. Subsequently, the underlying driver execution module uses the underlying control link health score formula to evaluate the real-time reliability of the control link:

[0184] ;

[0185] in, This indicates the health score of the underlying control link; This indicates the instruction reception time deviation value; Indicates the communication timeout threshold; Indicates the communication failure attenuation factor; This means that when the instruction reception time deviation exceeds the communication timeout threshold, the health score will be limited to a value not less than zero.

[0186] Through the aforementioned limiting process, the health score of the underlying control link will not exhibit a negative value without engineering significance during prolonged communication interruptions. The underlying driver execution module can then execute normal operation, deceleration operation, pause operation, or forced shutdown based on the health score's range.

[0187] When the chassis service node issues underlying control commands normally, the command reception time deviation remains within a preset range. When a hardware access node malfunctions, a chassis service node malfunctions, the communication link is interfered with, or the upper-layer intelligent computing module fails, causing the command reception time deviation to exceed the communication timeout threshold, the underlying control link health score triggers a preset protection threshold. As one implementation, the communication timeout threshold can be set to 500ms; in other implementations, it can be dynamically configured based on vehicle speed, braking distance, and control cycle.

[0188] When a preset protection threshold is triggered, the underlying drive execution module determines that the vehicle's operating state is abnormal and initiates independent takeover logic. This independent takeover logic, at the microcontroller level, uses hardware interrupt signals, drive enable control terminals, brake control terminals, or contactor control terminals to forcibly reset the target speed value of the underlying travel drive to zero, or to cut off the drive enable of the underlying travel drive, causing the drive motor to enter a deceleration, braking, or stop state. Simultaneously, the underlying drive execution module drives the relay control unit to disconnect the power supply to safety-related operational components.

[0189] Subsequently, the underlying driver execution module encapsulates the exception interruption report. The exception interruption report includes the fault diagnostic code, trigger source, trigger time, and current vehicle status. When the network communication link is available, the exception interruption report is uploaded to the cloud collaborative service module via the network communication unit; when the network communication link is unavailable, the exception interruption report is stored in the local cache and uploaded in chronological order after the network is restored.

[0190] S502 establishes a multi-channel manual intervention and cloud-based forced degradation control mechanism.

[0191] To provide remote and short-range monitoring during autonomous navigation, this embodiment establishes a control allocation architecture based on priority vectors. This architecture supports remote task commands from mobile applications, control commands via 4G remote links or web clients, cloud-based forced degradation commands, autonomous navigation control commands, and short-range takeover commands from radio control (RC) devices.

[0192] As a preferred approach, the underlying drive execution module continuously monitors the pulse width modulation signal input from the multi-channel remote control receiver and prioritizes safety-related actions such as emergency stop, braking, mode switching, warning light activation, and disconnection of the work load. Therefore, even in the event of an upper-level intelligent computing module malfunction, network interruption, or special operating conditions, the vehicle still possesses minimum local safety control capabilities.

[0193] When a logically valid bit is detected in a manual control handle, a cloud-based degradation command, a remote control command from a mobile application or web client, or an autonomous navigation control command, the system determines the current executing entity using a multi-source control arbitration analysis formula based on the valid flags of each control channel and their corresponding control weights.

[0194] ;

[0195] in, This indicates the control channel that has currently gained control; Indicates the control channel index; Indicates an RC remote control device or a manual short-range intervention channel; This indicates the cloud-based degradation control channel; This indicates a mobile application, web client, or 4G remote link control channel. Indicates the autonomous navigation control channel; This indicates the validity flag of the corresponding control channel, with a value of 0 or 1. This indicates the control weight of the corresponding control channel; Indicates the priority value for participating in arbitration when the control channel is active; This indicates that the control channel with the highest priority value is selected as the current execution entity.

[0196] By setting a valid control channel flag, the system can prevent invalid control sources from participating in arbitration based solely on preset weights, thereby enabling orderly switching between multiple control sources such as mobile applications, 4G remote links, web client control, cloud-based forced degradation, autonomous navigation, and RC remote control device short-range takeover.

[0197] In this embodiment, the control weight of the artificial short-range intervention channel The control weight of the cloud-based degradation control channel is set to 100. The control weight of the remote control channel is set to 50. The control weight of the autonomous navigation control channel is set to 30. Set to 10.

[0198] When the operator intervenes in the control, and the manual short-range intervention channel is valid. When the priority is 1, the control channel that currently gains control has the highest priority, as the manual short-range intervention channel has the highest priority. Switch to the manual short-range intervention channel. At this time, the underlying drive execution module stops parsing the motion planning route from the job control node and maps the manual signals into underlying control commands.

[0199] To reduce the mechanical shock during control switching, the system introduces a linear transition slope at the control output. As one implementation, the transition duration of the linear transition slope is 0.2 seconds; in other implementations, it can be adjusted based on vehicle mass, current speed, and driver response time.

[0200] In addition, the cloud-based collaborative service module can issue forced downgrade commands based on the returned video stream, vehicle operating status, fault codes, or mission area boundary information. When the network communication unit receives the emergency stop position in the forced downgrade command, and the forced downgrade command passes identity authentication, timestamp verification, and command integrity verification, the system's control switches from the autonomous navigation control channel to the cloud-based downgrade control channel, triggering deceleration, pause, stop, or brake hold without manual intervention.

[0201] When the network communication unit does not receive a downgrade instruction from the cloud, but detects an abnormal communication heartbeat, an abnormal underlying control link, a hardware emergency stop, a remote takeover, or a security boundary violation locally, the underlying driver execution module can still independently execute a local safe stop without relying on the real-time instructions of the cloud collaborative service module.

[0202] Throughout the mission, the underlying drive execution module continuously feeds back the vehicle's operating status to the operation control node. When the operation control node detects that the remaining percentage of the battery voltage is below 15%, it automatically modifies the motion planning route based on the pre-recorded coordinates of the charging station, the mission start point, the docking point, or the return point coordinates issued by the cloud collaborative service module, and guides the vehicle back to the corresponding return point.

[0203] For the specific circuit implementation of the above priority register configuration and signal decoding, those skilled in the art can use conventional pulse width modulation (PWM) signal decoding, level input detection, priority register, state machine control and interlocked output logic to implement it, which are well known technologies in the field and will not be described in detail here.

[0204] Specific application examples:

[0205] The following description, using a large-scale orchard self-propelled operation platform as an example, illustrates the installation method of the control system, positioning degradation calculation, underlying differential speed control, and prototype testing process of this invention. This embodiment is used to illustrate specific implementation methods of the invention and is not intended to limit the scope of protection of the invention.

[0206] In this embodiment, an integrated autonomous driving control box is installed on a large orchard self-propelled operation platform. During installation, a 12V, 24V, or 48V vehicle-side power supply is connected to the control box's power module, and converted by a power conversion unit to the protected power branch required by the system. A lidar is installed at the front top of the vehicle body, an RTK-GNSS antenna is installed above the center of the vehicle body, a binocular depth camera is positioned in the vehicle's forward field of view, and an IMU is fixed near the vehicle's center of gravity or integrated into the corresponding sensor module.

[0207] The underlying drive execution module connects to the travel drive, throttle actuator, brake actuator, lifting motor, damper motor, starter motor, lighting, warning lights, and other operational components. It also connects to the hardware emergency stop switch, brake control circuit, remote control receiver, and work load safety disconnect circuit. After the operator creates a work area and issues mapping commands via a mobile application or web client, the vehicle autonomously explores and maps within the defined area. Once mapping is complete, the operator can choose between taught driving or automatic path planning. The system records path parameters and corresponding action codes, which are automatically reproduced in subsequent tasks, enabling the vehicle to perform automatic obstacle avoidance, path tracking, and coordinated control of the actuators during operation.

[0208] In this embodiment, when the vehicle is operating between orchards, the absolute positioning signal of the Global Navigation Satellite System (GNSS) is attenuated or briefly lost due to the dense canopy obstruction. The operation control node monitors the positioning status in real time and assesses the duration of the satellite signal loss. When 5 seconds have elapsed, the adaptive degradation fusion pose formula is invoked to perform global position transition calculation.

[0209] Obtain the visual inertial inferred pose output by the visual inertial state estimator at the current moment. Its coordinate vector is assumed to be (10.0, 5.0, 0); at the same time, the absolute positioning pose of the Global Navigation Satellite System is... The lock-in is the most recent valid state that met the positioning quality requirements before signal loss, with coordinate vectors (10.5, 5.2, 0). The system sets the initial confidence weights for absolute positioning. The signal attenuation time constant is 1.0. It is 0.1.

[0210] The globally optimal 3D pose is calculated using an adaptive degradation fusion pose formula, which is as follows:

[0211] ;

[0212] Substitute the above values ​​into the calculation. The pose deviation between absolute positioning and locally extrapolated values. for:

[0213] ;

[0214] Degradation compensation coefficient that decays over time for:

[0215] ;

[0216] The dynamically weighted pose correction is:

[0217] ;

[0218] Therefore, the global optimal 3D pose for:

[0219] ;

[0220] The above calculation results show that during the positioning signal decay period, the system reduces the influence weight of the most recent absolute positioning data on the current pose and mainly relies on visual inertial odometry to maintain continuous pose output, thereby reducing the impact of positioning changes on the underlying control.

[0221] The chassis service node extracts the underlying desired velocity vector from the updated motion planning path. The desired linear velocity at the chassis center is then set. The desired angular velocity at the chassis center is 0.2 m / s, or 200 mm / s. It is 0.1 rad / s; the vehicle wheelbase in the vehicle hardware configuration parameters. It is 0.8m.

[0222] The system uses the inverse kinematics formula for differential speed to calculate the target linear velocities of the left and right drive wheels, and further converts these velocities into the target speeds of the drive motors by combining the drive wheel radii and reduction ratios. The inverse kinematics formula for differential speed is:

[0223] ;

[0224] After substituting the values, the left and right speed deviations caused by steering are:

[0225] ;

[0226] Target linear velocity of the left drive wheel for:

[0227] ;

[0228] Target linear velocity of the right drive wheel for:

[0229] ;

[0230] The chassis service node encodes the above calculation results into differential control bus frames or drive control messages and sends them to the drive motors on both sides for execution.

[0231] To verify the control effect of the invention under prototype conditions, prototype testing was conducted in a large orchard setting. The test environment included two types of areas: flat, open grassland and orchards. The test platform was a self-propelled operating platform connected to the upper-level intelligent computing module and the lower-level drive execution module. During the test, a 12V vehicle power supply or a protected power branch converted by the power conversion unit was used to power the bus communication unit, network communication unit, and various sensors. When the test chassis provided 48V power, the power conversion unit converted the 48V DC voltage to the 12V, 24V, or other protected power branches required by the system before powering it.

[0232] After the system is powered on, the hardware access node establishes a communication handshake connection with the RTK-GNSS positioning module, binocular depth camera, LiDAR, IMU, underlying walking driver, and operation execution components, and detects the time synchronization status, emergency stop input status, remote control takeover status, and underlying communication heartbeat status. The following test data is used to illustrate the prototype's operating performance under specific scenarios, speeds, and sensor combinations, and is not intended to limit the implementation of the invention under other terrains, speeds, or sensor combinations.

[0233] Straight-line movement tests were conducted on a flat, open grassland. The operator guided the vehicle to establish a 25m long moving baseline via an external control interface. After the system entered the baseline parameters, it switched to automatic operation mode and maintained a cruising speed of 200mm / s. During the test, the lateral position difference between the chassis's automatic movement trajectory and the manually taught baseline was measured, and 10cm was set as the engineering judgment limit for straight-line tracking. The test results are shown in Table 1.

[0234] Table 1. Test data of the prototype under straight-line tracking conditions in flat and open grassland (running speed: 200 mm / s, judgment threshold: 10 cm).

[0235]

[0236] Variable curvature path tracking tests were conducted in a grassland area. A continuous W-shaped curve with a length of 15m was manually planned, and six sampling points were extracted at equal intervals along this section. This test was used to verify the trajectory control performance of the local planning algorithm under steering-constrained conditions; when the prototype adopts a TEB-type trajectory optimization strategy, it can also be used to verify the control effect of time elastic constraints on curve path tracking. Considering the possibility of physical slippage of the equipment under variable curvature conditions, the test judgment benchmark was set to 20cm. The test results are shown in Table 2.

[0237] Table 2. Test data of the prototype under W-curve tracking conditions in flat, open grassland (judgment threshold: 20cm)

[0238]

[0239] Static obstacle avoidance tests were conducted in an orchard setting. A manually operated vehicle navigated an S-shaped path containing multiple fruit trees, while the system simultaneously generated a local cost map including information on the tree boundary expansion. When the vehicle autonomously replicated the path, the physical distances between the vehicle and the surrounding tree trunks were measured and compared with those observed during manual control. This test covered eight tree-avoidance maneuvers to verify the spatial protection capability of multi-sensor fusion mapping against irregular objects. The test results are shown in Table 3.

[0240] Table 3. Test data of obstacle avoidance distance of the prototype under static obstacle avoidance conditions in the orchard (Route: tree shuttle curve)

[0241]

[0242] See attached document Figure 8 , Figure 8 The horizontal axis represents the uniformly divided test sampling sequence number, and the vertical axis represents the trajectory offset or obstacle avoidance distance fluctuation under various working conditions. To reduce data point occlusion, data points under the same sampling sequence are slightly misaligned horizontally. Light gray dots correspond to smooth straight-line tracking tests, medium gray squares correspond to curve corner tracking tests, and dark gray triangles correspond to fruit tree collision avoidance and detour tests. The black dashed line in the figure represents the 10cm straight-line tracking judgment limit, and the black dotted line represents the 20cm complex curve judgment limit.

[0243] Combination Figure 8 As shown in Tables 1 to 3, the system exhibits different control performances under varying environmental resistance and path constraints. The straight-line tracking data in Table 1 indicates that at a cruising speed of 200 mm / s, the lateral offset of the vehicle body remains within the 10 cm threshold, demonstrating that the underlying differential drive unit can complete path tracking on straight sections according to the upper-level control commands.

[0244] Combined with Table 2 and Figure 8 The distribution of gray squares in the data shows that most reference points on the W-shaped curve path deviate within the 20cm engineering judgment limit. However, test point 4 has an offset of 35cm, exceeding the engineering judgment limit for this section. On-site verification revealed that the friction coefficient of the grass surface in this area is low, accompanied by tire lateral slippage, causing a deviation between the vehicle's actual trajectory and the planned trajectory. Under this condition, the local planner replanned the local path based on kinematic constraints, obstacle distances, and vehicle attitude stability. This single-point deviation demonstrates that under low adhesion or sideslip conditions, trajectory tracking stability can be improved by reducing the target speed, increasing the local safety boundary, adjusting the kinematic constraint weights, or triggering manual verification. The above test results are used to illustrate the system's control response and safety boundary setting methods under complex ground conditions and do not indicate that the system can maintain the same accuracy under all curvature and all ground adhesion conditions.

[0245] In tests conducted in orchards, Table 3 and Figure 8 The dark gray triangular distribution in the image indicates that, in autonomous obstacle avoidance mode, the chassis system reserves physical avoidance space based on the local cost map, vehicle outline dimensions, and the outward extension range of the operation execution components. The distance differences between the two obstacle avoidance maneuvers reached 20cm and 30cm, respectively. LiDAR point cloud data from the orchard environment shows that the tree trunks, canopies, and drooping branches are irregularly distributed. When constructing the local cost map, the system performs two-dimensional outward expansion calculations on low-reflectivity edges, discrete point cloud regions, and areas that may interfere with the operation execution components.

[0246] The aforementioned dilation process manifests at the data level as a change in the automatic obstacle avoidance distance relative to the manual remote control distance. The underlying algorithm adjusts the isolation boundary between the vehicle and obstacles based on the dilated grid, thereby reducing the probability of physical interference between fruit tree branches, trunk edges, and the operating components. Test data shows that the system can adjust the safe obstacle avoidance area of ​​the equipment based on perception feedback for irregular outdoor obstacles; the specific obstacle avoidance distance is affected by sensor installation location, point cloud density, target reflectivity, vehicle speed, and local cost map dilation parameters.

[0247] In another embodiment, the control system is installed on a factory inspection vehicle or a factory transport vehicle. Due to the presence of semi-indoor areas, factory passageways, stacked obstacles, and areas with fluctuating GNSS signals within the factory area, the system prioritizes local positioning using lidar and IMU, and provides global coordinate correction through an RTK-GNSS positioning module. The mobile application or web client can set inspection routes, stopping points, and operating rules. The upper-level intelligent computing module generates navigation instructions based on the map and task list, while the lower-level drive execution module drives the vehicle to complete start-stop, steering, lighting, warning, and braking linkages.

[0248] When the system detects an obstacle within the effective field of view and effective detection range of the sensors, it prioritizes deceleration or stopping and replans the local path based on traffic conditions. As a preferred approach, when the forward, backward, or circumferential sensor coverage is sufficient and the target reflectivity meets the detection conditions, the detection range of the local cost map can be set to a preset distance around the vehicle, such as 40m. When there are sensor blind spots behind or to the side, the system compensates through rear sensors, surround-view sensors, chassis safety boundary models, or low-speed limiting strategies.

[0249] In another embodiment, the system enters remote management mode. The network communication unit uploads vehicle status, current location, fault codes, task progress, sensor summaries, log information, and video streams to the cloud-based collaborative service module via a 4G router or Wi-Fi communication link. Remote personnel can issue start / stop, return, pause, continue, emergency stop, route switching, task deletion, or OTA update commands via mobile application or web client.

[0250] When communication malfunctions, the vehicle deviates from the set safety boundary, the underlying communication heartbeat malfunctions, hardware emergency stop is triggered, remote control takeover is triggered, or the upper-level intelligent computing module fails, the underlying drive execution module switches to safety mode and performs actions such as brake holding, disconnecting safety-related workloads, activating warning lights, setting the speed to zero, and caching or uploading abnormal interruption reports. At this time, the system allows the RC remote control device to perform short-range takeover. The aforementioned safety mode is triggered and executed by the vehicle's local underlying drive execution module; the cloud-based collaborative service module is used for remote monitoring and recording, but is not the sole source of safety triggering.

[0251] This invention is not limited to the embodiments described above. For different vehicle models and different operating scenarios, the underlying walking drive can be replaced with a hub motor drive, track motor drive, servo drive, steering wheel drive mechanism, or hydraulic actuator; the number, installation position, and scanning range of the LiDAR can be adjusted; the placement of the binocular depth camera, RTK-GNSS positioning module, and IMU can be adjusted; and the number of relays, the number of standardized wiring terminals, the communication method, the number of power supply branches, and the type of operating components can also be adjusted according to operational requirements.

[0252] Without departing from the technical concept of this invention, any equivalent replacement or improvement of the automatic driving control of mobile work vehicles by adopting the same or equivalent integrated control box or control assembly architecture as this invention, and combining standard interface system, multi-sensor fusion positioning and navigation link, path recording and path reproduction mechanism, automatic obstacle avoidance mechanism, remote task management mechanism and underlying independent safety execution mechanism, shall fall within the protection scope of this invention.

Claims

1. A universal automatic driving control system for indoor and outdoor mobile work vehicles, characterized in that, include: The upper-level intelligent computing module is used to perform environmental perception, map building, navigation and positioning, path planning and operation logic management, and generate underlying control commands that match the current mobile operation platform based on vehicle type, chassis parameters and operation equipment parameters. The underlying drive execution module is used to receive the underlying control commands and drive the vehicle hardware to perform walking and other operational actions; the underlying drive execution module is also used to collect chassis drive feedback, actuator feedback and safety status signals, and generate vehicle operating status; the underlying drive execution module includes a safety takeover unit independent of the upper-level intelligent computing module, which is used to execute speed zeroing, brake holding and work load disconnection in the event of an anomaly, thereby enabling the vehicle to enter a safe output state; The cloud-based collaborative service module is used to receive the vehicle's operating status, perform remote monitoring and task scheduling, generate cloud-based task instructions, and send the cloud-based task instructions to the upper-layer intelligent computing module.

2. The universal automatic driving control system for indoor and outdoor mobile work vehicles according to claim 1, characterized in that, The upper-layer intelligent computing module includes: The power conversion unit is used to connect to the vehicle-side power supply and convert the vehicle-side power supply into multiple power supply voltages required by the system. The sensor access unit is powered by the protected power supply branch of the multi-channel power supply voltage, and is used to collect multi-source sensing data generated by the real-time dynamic differential global navigation satellite system positioning module, binocular depth camera, lidar and IMU, and receive external time reference. The network communication unit is powered by the protected power supply branch and is used to establish a two-way network communication link between the vehicle and the cloud collaborative service module, upload the vehicle's operating status, and receive cloud task instructions.

3. A universal automatic driving control system for indoor and outdoor mobile work vehicles according to claim 2, characterized in that, The upper-layer intelligent computing module deploys a robot operating system middleware, which includes: Hardware access nodes are used to parse the multi-source sensing data and publish standardized topics in the system; The task control node is used to receive the standardized topics and the cloud task instructions, and to execute the environmental perception, map building, navigation and positioning and path planning. The chassis service node is used to monitor the motion planning route and convert it into the underlying control commands that match the underlying drive execution module.

4. A universal automatic driving control system for indoor and outdoor mobile work vehicles according to claim 3, characterized in that, The underlying driver execution module includes: The bus communication unit is used to receive the underlying control commands and convert them into differential control bus frames or drive control messages, and send them to the underlying travel driver to complete the closed-loop speed control of the left and right drive motors of the vehicle, and obtain fault feedback information. The relay control unit is used to receive the underlying control commands and convert them into switching signals to control the power enable, direction selection, start / stop status and safety power-off status of the work execution component, and to detect the contact feedback status.

5. A universal automatic driving control system for indoor and outdoor mobile work vehicles according to claim 3, characterized in that, The job control node is used to perform the navigation and positioning, wherein the job control node is used to: Process inertial measurement unit data and image sequences to output local visual-inertial inference pose; It is also used to lock the most recent valid global navigation satellite system absolute positioning attitude when the global navigation satellite system signal switches from an effective state to a short-term failure state; The system integrates the absolute positioning pose of the global navigation satellite system with the visual-inertial inference pose to determine the globally optimal three-dimensional pose, and then maintains the continuous output of vehicle positioning results based on the globally optimal three-dimensional pose to complete the navigation and positioning.

6. A universal automatic driving control system for indoor and outdoor mobile work vehicles according to claim 3, characterized in that, The job control node is used to perform environmental perception, map building, and path planning, wherein the job control node is used for: Multi-source sensing data is uniformly projected onto a two-dimensional local grid and low-lying protruding obstacles are identified to generate a local cost map; Based on the local cost map, the local trajectory cost is calculated using the time elastic band trajectory optimization cost formula; The path planning is completed by optimizing discrete trajectory point configurations that reduce the cost of local trajectories using nonlinear graph optimization and outputting a motion planning route. In the local cost map generation, the operation control node is used to mark the grid area as an obstacle-occupied state when the reflectance change gradient of the grid area exceeds a preset reflectance threshold; the reflectance threshold is a gray level pre-calibrated based on the reflectance difference between the surface material of the operation environment and the obstacle material.

7. A universal automatic driving control system for indoor and outdoor mobile work vehicles according to claim 4, characterized in that, The chassis service node is used to generate underlying control commands that match the current mobile work platform based on the vehicle type, chassis parameters, and work implement parameters, wherein the chassis service node is used for: Extract the desired linear velocity and desired angular velocity of the chassis center from the system topic; Based on the desired linear velocity and desired angular velocity of the chassis center, the differential inverse kinematics model corresponding to the vehicle type, and the wheelbase value determined by the chassis parameters, the target linear velocities on both sides are calculated. The drive motor speed command is calculated based on the target linear velocities on both sides and the mechanical characteristic parameters of the underlying driver. The drive motor speed command is encapsulated in the actuator action code mapped from the working tool parameters to generate the underlying control command.

8. A universal automatic driving control system for indoor and outdoor mobile work vehicles according to claim 4, characterized in that, The safety takeover unit within the underlying drive execution module is used to execute the speed zeroing, brake holding, and work load disconnection in the event of an anomaly, thereby enabling the vehicle to enter the safe output state. The safety takeover unit is used to: Record the arrival time of the underlying control command data packets in two adjacent frames and calculate the command reception time deviation value; The underlying control link health score is calculated based on the instruction reception time deviation value and the communication timeout threshold value. When the health score of the underlying control link triggers the preset protection threshold, it is determined that an abnormality has occurred, and then the speed is set to zero, the braking is maintained and the work load is disconnected to enter the safe output state, and an abnormal interruption report is generated for uploading. The communication timeout threshold is the maximum allowable time interval for determining the failure of the upper-layer communication link; the preset protection threshold is the condition triggered when the health score of the lower-layer control link is lower than a preset safety value.

9. A universal automatic driving control system for indoor and outdoor mobile work vehicles according to claim 4, characterized in that, The underlying drive execution module is used to receive the underlying control commands and drive the vehicle hardware to perform the walking and other operational actions. The underlying drive execution module includes an arbitration unit, which is used for: Continuously monitor the input status of multiple control channels and extract the valid flags and preset control weights corresponding to each control channel; Based on the valid flag and the preset control weight, the control channel with the highest priority value is determined as the current execution entity; The corresponding underlying control instructions or manual instructions are obtained based on the current executing entity, and the vehicle hardware is driven to perform the corresponding walking and other operational actions.

10. A universal automatic driving control system for indoor and outdoor mobile work vehicles according to claim 3, characterized in that, The upper-layer intelligent computing module is used to execute the job logic management and support the teaching and learning mode, wherein the upper-layer intelligent computing module is used for: Record the global optimal three-dimensional pose of the vehicle during its driving process and simultaneously read the corresponding switch signal status of the system; The switch signal state and the globally optimal three-dimensional pose are bound together to form a structured teaching trajectory; In subsequent operation phases, the structured teaching trajectory is invoked to reproduce the path in the target environment and trigger automatic operation actions, thereby completing the operation logic management.

Images