Split robot pairing method and split robot

Abstract

The application relates to the technical field of modular robots, in particular to a split robot pairing method and split robot, which are applied to a master and a slave base connected through a single-wire communication bus; wherein the method comprises the following steps: the master and the slave base are configured with ports connected with the single-wire communication bus as input modes to detect the physical connection between the master and the slave base; after detecting that the physical connection is successful, the master switches the port of the master to a serial port sending mode, sends an authentication instruction to the slave base, and switches back to the serial port receiving mode to wait for a response; after detecting the authentication instruction, the slave base switches the port of the slave base to the serial port sending mode, and sends a response result to the master; the master receives and verifies the response result, and completes the bidirectional handshake authentication with the slave base.

Description

Technical Field

[0001] This invention relates to the field of modular robot technology, and more particularly to a method for pairing split-type robots and a split-type robot. Background Technology

[0002] With the popularization of robotics technology, modular robot designs with interchangeable functional bases are becoming a trend. This requires the host machine to be able to automatically, reliably, and safely identify and pair different bases.

[0003] The existing technology has the following main shortcomings: Complex interfaces: The common use of multi-line standard communication interfaces (such as UART, I2C, SPI) requires multiple connection pins, which increases the cost, size and insertion / removal alignment complexity of the connector, and reduces mechanical reliability.

[0004] Process separation: Connection detection, identity recognition, and function driving are typically implemented by independent hardware circuits and software protocols. For example, physical connections are determined through dedicated detection pins, and data exchange is then conducted via a communication bus. This architecture results in low resource utilization and system complexity.

[0005] Weak security: Most simple pairing solutions lack encryption and authentication mechanisms, making them vulnerable to attacks such as unauthorized dock access or tampering with communication data, resulting in low system security.

[0006] Cost and power consumption: Although wireless (such as Bluetooth, Wi-Fi) pairing solutions do not require physical connection detection, they have problems such as cumbersome pairing process, high power consumption, real-time performance affected by the environment, and high cost.

[0007] Therefore, there is an urgent need for a complete pairing scheme that can integrate physical connection detection, encrypted handshake, identity information exchange and final confirmation on a single communication link through a minimal physical connection, so as to achieve low-cost, highly reliable and highly secure rapid pairing of modular robots. Summary of the Invention

[0008] Based on this, it is necessary to address the technical problems of existing technologies, such as cumbersome pairing process, high power consumption, real-time performance affected by the environment, and high cost, and propose a split-type robot pairing method and a split-type robot.

[0009] Firstly, a method for pairing split-type robots is provided, applied to a host robot and a slave robot base connected via a single-wire communication bus; the method includes: The host and the slave base are configured with their respective ports connected to the single-wire communication bus in input mode to detect the physical connection between them; After detecting a successful physical connection, the host switches its own port to serial port transmission mode, sends an authentication command to the slave dock, and then switches back to serial port reception mode to wait for a response. After detecting the authentication command, the slave device switches its port to serial port transmission mode and sends a response result to the host. The host receives and verifies the response result, completing the two-way handshake authentication with the slave base.

[0010] Preferably, the host switches its own port to serial port transmission mode and sends an authentication command to the slave dock, including: The host reconfigures its own port from input mode to serial port transmission mode, and the serial port transmission mode is UART transmission mode; In the UART transmission mode, the host generates and sends authentication commands.

[0011] Preferably, the host and the slave dock are configured with their respective ports connected to the single-wire communication bus in input mode to detect the physical connection between them, including: The host computer configures the port connected to the single-wire communication bus to a pull-down input mode. The slave base is configured with the port connected to the single-wire communication bus in pull-up input mode; When the host detects a stable high level on the port, it determines that the host and the slave dock are physically connected and ready.

[0012] Preferably, the step of determining that the physical connection between the host and the slave dock is ready when the host detects a stable high level on the port includes: If the host determines that a high level has been detected on the port for a predetermined number of consecutive detection cycles, it determines that the host and the slave base are physically connected and ready.

[0013] Preferably, the method further includes: after detecting the authentication command, the slave device switches its port to serial port transmission mode and sends a response result to the host, including the following steps: After the slave base detects the falling edge of the start bit, it switches its own port to serial port receiving mode, which is UART receiving mode. After receiving the authentication command, the slave device switches its port to serial port transmission mode and sends the response result to the host.

[0014] Preferred options also include: The host sends an identity information reading instruction to the slave dock, the identity information reading instruction including a first random number generated by the host; After receiving and verifying the identity information reading instruction, the slave device reads the identity information from its memory, and organizes the first random number, the second random number it generates, and the identity information into an identity response frame, encrypts it, and sends it to the host. The host receives and decrypts the identity response frame, verifies that the first random number is correct, obtains the identity information of the slave dock, and completes identity authentication; After completing identity authentication, the host detects whether the single-wire communication bus is at a high level; If so, the entire pairing process is considered complete; If not, the connection is determined to be abnormal, the host switches its own port back to the drop-down input mode, and resets the communication status to the physical connection detection stage.

[0015] Preferably, the identity information reading instruction includes a first random number; The identity response frame includes a first random number, a second random number, and the identity information of the slave device.

[0016] Preferably, after the identity authentication step, the method further includes: Switch the single-wire communication bus to drop-down input mode. Switch the communication bus of the slave device to a static drive mode that continuously outputs a high level.

[0017] Preferably, the step of the slave device receiving the identity information reading instruction and verifying it before replying to the host with an identity response frame includes: The slave device receives the identity information reading instruction, and the identity authentication includes the host's identity ID; Obtain the slave docking station identity ID, combine the host ID and the slave docking station ID into an identity response frame and encrypt it; The encrypted identity response frame is sent to the host.

[0018] Secondly, a split-type robot is provided, including: A master unit and a slave unit docking station, wherein the master unit is connected and communicates with the slave unit docking station via a single-wire communication bus; The host is configured to detect the physical connection between the host and the slave base by configuring their respective ports connected to the single-wire communication bus as input modes. The host is also used to switch its own port to serial port transmission mode after detecting a successful physical connection, send an authentication command to the slave dock, and switch back to serial port reception mode to wait for a response. The slave dock is used to switch its own port to serial port transmission mode and send a response result to the host after detecting the authentication command; The host is also used to receive and verify the response result, and complete the two-way handshake authentication with the slave base.

[0019] Beneficial effects: This application utilizes only a single-wire communication bus and cleverly switches I / O state machines to reuse all functions of physical connection detection, bidirectional encrypted communication, and final state confirmation. This eliminates the need for additional dedicated detection pins and circuits, minimizing the cost of connectors and interface circuits. Simultaneously, it employs a three-stage verification process: "initial level detection - encrypted data interaction - final level confirmation." This process not only significantly improves connection reliability but also effectively resists physical layer replay attacks and man-in-the-middle eavesdropping risks. The level states at each stage are strictly controlled, ensuring that the authentication process is unbypassable and unpredictable. The entire mechanism maintains high real-time performance and low power consumption even in resource-constrained embedded scenarios, making it suitable for large-scale deployments of intelligent peripheral collaborative systems. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] in: Figure 1 This is an application environment diagram of a split-type robot pairing method in one embodiment; Figure 2 This is a flowchart of a split-type robot pairing method in one embodiment. Detailed Implementation

[0022] The technical solutions of 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, not all, of the embodiments of the present invention. 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.

[0023] The abbreviations and definitions of terms used in this application are as follows: UART: Universal Asynchronous Receiver / Transmitter, whose full Chinese name is "通用异步收发传输器", is a hardware communication interface that converts data bytes into serial bit streams bit by bit for transmission and reception. In this patent, it is used for serial port command transmission between the host and the slave base.

[0024] GPIO: General Purpose Input / Output, whose full Chinese name is "通用输入输出端口", is a pin on a microcontroller that can be programmed and configured. It can be set to input mode to read external electrical levels or output mode to drive bus electrical levels. In this patent, it is used to configure the pull-down input mode of the host and the pull-up input mode of the slave.

[0025] AES: Advanced Encryption Standard, whose full Chinese name is "高级加密标准", is a symmetric encryption algorithm. Both communication parties use the same key for data encryption and decryption. In this patent, it is used to encrypt and protect the random number challenge in the PING command and the identity information in the identity response frame.

[0026] CRC: Cyclic Redundancy Check, whose full Chinese name is "循环冗余校验", is a data error detection algorithm. The sender calculates a check value based on the data content and appends it to the end of the frame, and the receiver recalculates and compares it to determine whether the data is damaged during transmission. In this patent, it is used to verify the integrity of command frames and response frames.

[0027] VCC: Voltage Common Collector, whose full Chinese name is "电源电压" or "集电极电源电压", originates from the positive power supply connected to the collector in a bipolar transistor circuit. In digital circuits, it generally refers to the positive power supply terminal of the circuit, such as 3.3V or 5V. In the present application, it is used to provide a high-level bias voltage for the pull-up resistor of the slave base.

[0028] GND: Ground, whose full Chinese name is "地" or "接地", represents the zero-voltage reference point of the circuit and is the common terminal of the current loop. In this patent, it is used to connect the other end of the pull-down resistor of the host, so that the bus is clamped to 0V when idle.

[0029] I / O: Input / Output, whose full Chinese name is "输入 / 输出", generally refers to ports or buses used for data input or output in digital circuits. In this patent, both the communication bus port of the host and the communication bus port of the slave belong to I / O ports.

[0030] BUS: Bus, short for "bus", refers to a communication transmission line shared between multiple devices. In this patent, the single-wire communication bus specifically refers to the single data communication line between the host and the slave device base.

[0031] MCU: Microcontroller Unit, is an embedded control chip that integrates a processor core, memory, I / O ports, and communication interfaces onto a single chip. This patent is used to implement pairing logic, encryption / decryption, and communication protocol processing in the host and slave docks.

[0032] PCB: Printed Circuit Board, is the physical support and electrical connection carrier for electronic components. In this patent, both the pull-down resistor and the pull-up resistor are soldered onto the PCB.

[0033] ESD: Electro-Static Discharge, also known as "static discharge," refers to the phenomenon of static electricity transferring between objects with different potentials, which can damage electronic components. The bus interface in this patent can be equipped with ESD protection circuitry to improve reliability.

[0034] PING: Packet Internet Groper, also known as Internet Packet Detector (often simply called "PING" or "network connectivity test command"), is a standard diagnostic tool and command in the TCP / IP network protocol stack. It tests network connectivity between the source and target hosts, measures round-trip time, and determines packet loss rate by sending ICMP (Internet Control Message Protocol) Echo Request messages to the target host and waiting to receive Echo Reply messages. In computer networks, the PING command is the most basic and commonly used method for troubleshooting network problems.

[0035] The present invention provides a method for pairing split-type robots, which can be applied to applications such as... Figure 1In this application environment, the host 100 communicates with the slave base 200 via a single-wire communication bus. A method for pairing split-type robots is characterized by its application to a host and slave base connected via a single-wire communication bus. The host and slave base configure their respective ports connected to the single-wire communication bus as input modes to detect the physical connection between them. After successfully detecting a physical connection, the host switches its port to serial port transmission mode, sends an authentication command to the slave base, and switches back to serial port reception mode to wait for a response. Upon detecting the authentication command, the slave base switches its port to serial port transmission mode and sends a response result to the host. The host receives and verifies the response result, completing the bidirectional handshake authentication with the slave base. By utilizing only a single-wire communication bus and cleverly switching IO state machines, all functions—physical connection detection, bidirectional encrypted communication, and final state confirmation—are reused. This eliminates the need for additional dedicated detection pins and circuits, minimizing the cost of connectors and interface circuits. The host 100 and slave base 200 are physically connected via a single-wire communication bus (BUS), a power line (VCC), and a ground line (GND). The host 100 can be a robot body control unit, and the slave base 200 can be a walking chassis, robotic arm, charging dock, or other functional modules. The communication bus port of the host 100 is connected to ground (GND) via a pull-down resistor (e.g., 10kΩ), and the communication bus port of the slave base 200 is connected to the power supply (VCC) via a pull-up resistor (e.g., 4.7kΩ). These resistors form the hardware basis for low-power physical connection detection.

[0036] Please see Figure 2 As shown, Figure 2 A flowchart illustrating a method for pairing split-type robots according to an embodiment of the present invention includes the following steps: S1: The host and slave docks are configured with their respective ports connected to the single-wire communication bus as input mode to detect the physical connection between them; S2: After detecting a successful physical connection, the host switches its own port to serial port transmission mode, sends an authentication command to the slave dock, and switches back to serial port reception mode to wait for a response. S3: After detecting the authentication command, the slave device switches its port to serial port transmission mode and sends the response result to the host. S4: The host receives and verifies the response result, completing the two-way handshake authentication with the slave base.

[0037] Specifically, a single-wire communication bus refers to a communication bus with only one data line between the host and the slave base. All detection, authentication, and communication are performed on this single line in a half-duplex time-division manner.

[0038] Input mode refers to the GPIO port being configured as a digital input state, not actively driving the bus, but only reading the external level. At this time, the port is at high impedance and has minimal impact on external circuits.

[0039] Pull-down input mode is a special configuration of input mode where the port is connected to ground (GND) via a pull-down resistor, and the bus is clamped to a low level (0V) when idle.

[0040] In pull-up input mode, the port is connected to the power supply (VCC) via a pull-up resistor, and the bus is biased to a high level (VCC) when idle.

[0041] Serial port transmission mode refers to the port being configured as UART asynchronous transmission mode (push-pull output), which can actively drive the bus to a high or low level and send start bits, data bits, and stop bits according to the set baud rate (such as 115200).

[0042] Serial port receive mode refers to the port being configured as asynchronous receive mode (high impedance input), where the hardware automatically samples the bus level according to the baud rate and parses the start bit, data bit, and stop bit.

[0043] The authentication command is the first command sent by the host to the slave device to initiate the secure handshake process; a typical example is the PING command.

[0044] Two-way handshake authentication refers to the process by which the master and slave devices verify each other's identity. The master verifies the slave device's identity by sending a response frame containing the slave device's identity information. It checks whether the first byte of the response frame is the response code corresponding to the PING command (such as 0x81). If so, it confirms that the slave device is online and has a legitimate identity, and then sends a read command with CRC check. The slave device verifies that the command sent by the master device is in the correct format, thus achieving two-way confirmation.

[0045] The following explanation uses the insertion of a companion robot's main unit into its adapter base as an example. Initially, the main unit's port is configured in pull-down input mode (pull-down resistor connected to GND), and the bus level is 0V. The slave base's port is configured in pull-up input mode (pull-up resistor connected to 3.3V). When the user inserts the robot into the slave base, the pull-up resistor on the slave base and the pull-down resistor on the main unit form a series voltage divider, raising the bus voltage to above the main unit's high-level threshold. This indicates a successful physical connection. Subsequently, the main unit switches to serial port transmit mode, sends a command frame, and immediately switches to serial port receive mode after sending. The slave base receives the command and sends a response frame (response result) to the main unit. The main unit receives the response result and verifies its consistency; if they match, the two-way handshake is successful.

[0046] For example, after physical connection detection is completed, the host performs the following operations: First, it reconfigures the bus I / O from GPIO input mode to serial port transmit mode, mapping it to the serial port transmit function; then, it initializes the serial communication peripheral, setting the baud rate to 115200, data bits to 8 bits, stop bits to 1 bit, and no parity; next, it constructs an authentication command frame (e.g., a PING command), including a frame header of 55AA, command code 01, data length 0010, 16 bytes of AES-encrypted random number ciphertext, and 4 bytes of CRC32 checksum; finally, it sends the frame through the serial communication peripheral. After transmission, the host immediately disables the transmitter, enables the receiver, and switches to serial port receive mode to wait for a response. This application reuses all functions—physical connection detection, bidirectional encrypted communication, and final status confirmation—using only a single-wire communication bus and through clever I / O state machine switching. This eliminates the need for additional dedicated detection pins and circuits, minimizing the cost of connectors and interface circuitry.

[0047] This application achieves extremely simple hardware, with physical connection detection and communication completed by a single-wire bus and two resistors, eliminating the need for dedicated detection pins; it achieves extremely low static power consumption, as both parties are in input mode during the connection detection phase, without actively driving the bus, resulting in near-zero power consumption; it achieves automatic plug-and-play, requiring only physical plugging and unplugging, with the system automatically completing detection, authentication, and driver loading without manual intervention; and it achieves secure isolation, preventing unauthorized docks from passing authentication and isolating them before identity information can be read.

[0048] During the pairing phase, only identity information is exchanged. Throughout the pairing process, the read command sent by the host and the identity response frame replied by the slave are transmitted in plaintext, without involving encrypted calculations. This reduces the computational overhead and power consumption during the pairing phase, making it suitable for application scenarios where security requirements are not high but low cost and low power consumption are sought, such as simple toy robots or disposable pairing devices.

[0049] In this application, the host can be paired with various slave docks of different appearances and functions, as long as the connection port (i.e., the physical interface of the single-wire communication bus) of the slave dock is consistent with the interface of the host. The host identifies the type of dock currently inserted by reading the identity information of the slave dock (including dock type ID, firmware version, unique serial number, etc.), and loads the corresponding driver or executes different response behaviors accordingly, thereby realizing a modular entertainment experience of "one device for multiple uses".

[0050] Imagine a companion robot host (hereinafter referred to as "the host") shaped like a cute cartoon head, with a built-in display screen, speaker, microphone, and main control chip. Users can purchase or replace various slave bases with different appearances and functions for the host. Each base is toy-shaped and connects to the host through a unified single-wire communication bus interface.

[0051] For example, after the host successfully hands off the star-shaped base, it reads the type ID=0x8001 and then automatically performs the following actions: The display screen plays a starry sky animation with twinkling stars; the speaker plays a welcoming message: "Wow! You've hung me on a star! I'm your little star friend, my name is Liangliang, would you like to watch the stars with me tonight?"; at the same time, it enters "Goodnight Companion Mode": the volume is reduced, the light effect is dimmed, and soft music is played, suitable for bedtime interaction.

[0052] The base is a cat ear base (cartoon animal base): Base type ID=0x8002, Firmware version=0x0100, Serial number=“CAT_BASE_002”; Appearance design: Pink and white cat ear shape, with touchable soft rubber ears on both sides of the base, and built-in capacitive touch sensor; Interaction design: When the main unit is inserted into the base, "Pet Mode" is triggered. The display shows a cat animation, with eyes following the user's movement (like face tracking); the speaker plays a greeting: "Meow~ Hello! I am your little cat companion, my name is Mimi, touch my ears, and I will meow!"; Entering "Pet Companion Mode": When the user touches the ears on both sides of the base, a touch signal is returned through a single-wire communication bus, and the main unit emits different cat sounds ("Meow~", "Purr~") according to the signal, and makes a cute animation; At the same time, voice interaction is activated: the user says "Mimi, come here", and the main unit replies "I'm coming~ Meow!".

[0053] In some implementations, the host switches its own port to serial port transmission mode and sends authentication commands to the slave docking station, including: the host reconfiguring its own port from input mode to serial port transmission mode, the serial port transmission mode being UART transmission mode; in UART transmission mode, the host generates and sends authentication commands.

[0054] Specifically, UART transmit mode refers to the transmit function of a universal asynchronous transceiver (UART). The hardware automatically adds start bits (low level) and stop bits (high level) before and after the data byte, outputting bit by bit according to a preset baud rate. Reconfiguration refers to dynamically changing the function mapping of GPIO ports during software runtime, switching from general input / output mode to the transmit pin function of the UART peripheral. Utilizing the MCU's built-in UART hardware offers high transmission efficiency, eliminates the need for software timing simulation, and reduces the CPU load; the hardware UART is based on system clock frequency division, ensuring accurate baud rate and reliable communication; standard UART drivers can be reused across projects, reducing development costs.

[0055] In some implementations, step S1 includes: S11: The host configures the port connected to the single-wire communication bus to drop-down input mode; S12: The slave docking station configures the port connected to the single-wire communication bus as a pull-up input mode; S13: When the host detects a stable high level on the port, it determines that the physical connection between the host and the slave base is ready. Specifically, pull-down input mode means the port is connected to GND via a pull-down resistor, and the bus is pulled down to 0V when idle. Pull-up input mode means the port is connected to VCC via a pull-up resistor, and the bus is pulled up to VCC when idle. A stable high level refers to a continuous high level state confirmed by filtering, as opposed to high-level glitches caused by transient noise or contact jitter.

[0056] For example, in terms of hardware connection, an external resistor is connected to GND on the host bus pin, and an external resistor is connected to 3.3V on the slave bus pin. Regarding level calculation, the bus is 0V when not inserted (only pulled down by the host), and the bus voltage is higher than the host's high-level threshold after insertion. The host samples the bus level every 1ms; when eight consecutive samples are all high, a stable high level is determined, and the physical connection is ready. If a low level occurs midway, the counter is reset and re-accumulated. Both sides operate in input mode, relying solely on passive voltage division by resistors to change the level, without consuming dynamic current. Insertion triggers the connection, with the level changing immediately upon physical contact, eliminating the need for software polling or communication wake-up. The filtering logic (continuous multiple samplings) effectively filters contact jitter and electromagnetic interference, improving detection reliability.

[0057] In some implementations, the host determines that a high level has been detected for a predetermined number of consecutive detection cycles on the port, thus confirming that the host and slave base are physically connected.

[0058] Specifically, the detection period refers to the time interval at which the host samples the bus level once, typically ranging from 1ms to 10ms. The preset number refers to the minimum number of times a high level needs to be detected consecutively, typically ranging from 4 to 16 times. Consecutive means that a low level is not allowed in the sampling sequence; once a low level is detected, the counter is reset to zero.

[0059] For example, the detection period is set to 5ms, and the preset number is set to 8 times. The host samples the bus level every 5ms. If 8 consecutive samples are high, the counter reaches 8, and the connection is considered ready. If contact bounce occurs during insertion, for example, if the sampling sequence is [high, low, high, high, high, high, high, high], the counter changes to 1, 0, 1, 2, 3, 4, 5, 6. If 8 times are not reached, the counter continues to wait until 8 consecutive high levels appear. Continuous sampling effectively filters contact bounce (typically 5 to 20ms) to avoid false judgments; electromagnetic noise (such as spikes generated by motor start-stop) cannot trigger high levels multiple times consecutively and is effectively filtered out; the preset number can be adjusted according to the application scenario, with a larger value for high reliability scenarios and a smaller value for high response speed scenarios.

[0060] Optionally, the connection readiness can be confirmed by majority decision filtering. That is, N samples are taken within a fixed time window (e.g., 50ms). If the number of high-level signals is greater than or equal to a preset threshold, the connection is considered valid. This method is suitable for high-noise environments.

[0061] Optionally, the level can be calculated using a debouncing counter. That is, a counter is maintained, which increments by 1 when a high level is detected (upper limit is the threshold) and decrements by 1 when a low level is detected (lower limit is 0). The counter is considered valid when it reaches the threshold.

[0062] In some implementations, step S3 includes: S31: After detecting the falling edge of the start bit at the port of the slave device base, it switches its own port to serial port receiving mode, which is UART receiving mode. S32: After receiving the authentication command, the slave device switches its port to serial port transmission mode and sends the response result to the host. Specifically, the falling edge of the start bit refers to the instant when the bus transitions from an idle high level to a start bit low level in UART serial communication (high → low transition), which is the synchronization signal for the receiver to identify the start of a data frame.

[0063] A falling edge is the edge at which a digital signal level changes from high (logic 1) to low (logic 0), which is different from a low level (stable 0V state).

[0064] Switching to serial port receive mode means reconfiguring the port from GPIO input mode (or pull-up input mode) to UART receive function, enabling the hardware receiver.

[0065] Switching to serial port transmit mode means reconfiguring the port from UART receive mode to UART transmit function, enabling the hardware transmitter.

[0066] For example, during slave initialization, it is configured as a pull-up input mode and falling-edge interrupts are enabled. When the master sends the start bit of the authentication command to the bus, the bus level transitions from idle high to low, generating a falling edge. Upon detecting this falling edge, the slave triggers an interrupt service routine, switching the port from GPIO input mode to UART receive mode within 2 microseconds, enabling the receiver to begin receiving subsequent byte streams. After receiving and successfully verifying the authentication command, the slave switches the port to UART transmit mode, enabling the transmitter to send the response result. After transmission is complete, it can switch back to pull-up input mode as needed to wait for the next command.

[0067] The falling edge provides an accurate bit synchronization reference point for UART reception, ensuring correct sampling of subsequent data bits; the slave device can enter sleep mode in pull-up input mode and is only woken up and activated when the falling edge arrives, achieving low power consumption; the interrupt response time is in the microsecond range, and the start bit will not be lost; it detects the "falling edge" rather than the "low level" to prevent incorrect switching caused by abnormal low level of the bus.

[0068] Optionally, the slave device can enter deep sleep mode when silent, and a falling edge interrupt can be used as a wake-up source. After waking up, it switches to UART receive mode. Flag bits and delay checks can be added to the interrupt service routine to prevent false triggering due to noise.

[0069] In some implementations, it also includes: S5: The host sends an identity information reading instruction to the slave dock. The identity information reading instruction includes the first random number generated by the host. S6: After receiving and verifying the identity information reading instruction from the slave device, the slave device reads the identity information from its memory, and organizes the first random number, the second random number generated by itself, and the identity information into an identity response frame, encrypts it, and sends it to the host. S7: The host receives and decrypts the identity response frame, verifies the correctness of the first random number, obtains the identity information of the slave dock, and completes the identity authentication; S8: After completing identity authentication, the host checks whether the single-line communication bus is at a high level; if yes, the entire pairing process is considered complete; if no, the connection is considered abnormal, the host switches its own port back to the pull-down input mode, and resets the communication status to the physical connection detection stage.

[0070] Specifically, the first random number refers to a temporary random number (such as 16 bytes) generated by the host for this identity information exchange session, which is used to prevent replay attacks.

[0071] The second random number refers to the temporary random number generated by the slave device for this identity information exchange session, which is used for challenge-response communication in subsequent communications.

[0072] The identity information refers to a 64-byte data block pre-stored in the slave non-volatile memory, which includes the dock type ID, firmware version, unique serial number, power supply parameters, etc.

[0073] An identity response frame is an encrypted data frame returned by the slave device, with a payload structure consisting of a first random number, a second random number, and identity information.

[0074] Encryption refers to using a pre-shared key (such as AES-128) to symmetrically encrypt the entire payload, ensuring that it is not stolen or tampered with during transmission.

[0075] In step S4, after the host successfully verifies the response, it switches its port back to pull-down input mode, preparing to initiate the next stage of communication. After the slave device sends its response, it reconfigures its port to pull-up input mode and enables falling edge interrupt, waiting to receive the identity information reading command. In step S5, after the host detects that the bus is idle (e.g., after waiting 1ms), it switches its port to serial port transmission mode and sends the identity information reading command.

[0076] For example, the host generates a 16-byte random number R3, constructs an identity information read instruction frame (instruction code 0x03), and sends R3 after AES-128 encryption. The slave receives and decrypts R3, reads 64 bytes of identity information from memory (type ID = 0x1001 indicating chassis, version 0x0102, serial number, etc.), and simultaneously generates a 16-byte random number R4. The slave constructs a 96-byte response payload (R3 + R4 + identity information), encrypts it with AES-128, and sends it back to the host as an identity response frame (instruction code 0x04). Upon receiving the 96-byte ciphertext, the host performs a CRC check, decrypts it with AES-128, extracts the first 16 bytes to obtain R3', and compares it with the original R3. If they match, the host extracts the last 16 bytes to obtain R4 and saves it, extracts the last 64 bytes to obtain the identity information, parses it, and loads the corresponding driver based on the type ID. Subsequently, the host switches the bus back to pull-down input mode and checks if the bus level is high. If the signal is high and the filtering is successful, pairing is complete; if the signal is low, a connection error is detected, the host switches back to pull-down input mode, resets the communication state, and returns to the physical connection detection stage.

[0077] In this implementation, a different random number R3 is used for each session, and old identity response frames cannot be reused, effectively preventing replay attacks; encrypted transmission ensures that identity information is invisible and tamper-proof on the bus; after the host parses the identity information, it automatically loads the corresponding driver without user configuration, achieving plug-and-play functionality; when pairing confirmation fails, it automatically resets without manual intervention.

[0078] Optionally, the length of the random number can be 2 bytes, 4 bytes, 8 bytes, 12 bytes, 16 bytes, or 32 bytes. Security increases with the length, but communication overhead also increases.

[0079] Optionally, the identity information can be expanded to include the maximum supported communication rate, required power supply voltage / current, digital signature of the dock serial number, public key certificate, etc.

[0080] Optionally, the host can store a "whitelist of bound docks", allowing only serial numbers in the whitelist to pass authentication, thus achieving a unique binding between the host and a specific dock.

[0081] In some implementations, the identity information reading instruction includes a first random number; the identity response frame includes a first random number, a second random number, and the identity information of the slave device.

[0082] Specifically, the identity information read instruction refers to the instruction frame sent by the master to the slave, with the instruction code configurable as 0x03 (CMD_READ_ID), and the payload containing the first random number R3 generated by the master. The identity response frame refers to the instruction frame replied by the slave, with the instruction code configurable as 0x04 (CMD_ID_DATA), and the payload containing R3, R4, and encrypted identity information data.

[0083] For example, the structure of an identity information reading instruction frame is: Frame Header 1 (0x55), Frame Header 2 (0xAA), Instruction Code (0x03), Data Length (0x0010), 16-byte encrypted payload (AES-encrypted R3), and 4-byte CRC32 checksum. The structure of an identity response frame is: Frame Header 1 (0x55), Frame Header 2 (0xAA), Instruction Code (0x04), Data Length (0x0060), 96-byte encrypted payload (AES-encrypted R3 + R4 + identity information), and 4-byte CRC32 checksum. In the decrypted 96-byte payload, bytes 0 to 15 are R3 (compared to the host's input), bytes 16 to 31 are R4 (generated by the slave for subsequent use), and bytes 32 to 95 are the identity information. The instruction code clearly distinguishes the instruction type, facilitating protocol expansion; the return of R3 ensures that the slave's response is specific to the current request, preventing replay; R4 can serve as the initial challenge value for subsequent application communications.

[0084] In some implementations, after the authentication step is completed, the method further includes: switching the single-wire communication bus to a pull-down input mode, and switching the slave dock communication bus to a static drive mode that continuously outputs a high level.

[0085] Specifically, pull-down input mode means that after the master switches back to this mode, the bus is clamped to a low level by pull-down resistors when idle. If the slave outputs a high level normally, the bus is pulled high; if the slave disconnects, the bus automatically returns to a low level. Static drive mode means that the slave configures the bus I / O as push-pull output and continuously outputs a high level (VCC), without responding to any start bits or performing UART communication; that is, it does not perform any level toggling or communication behavior.

[0086] For example, after authentication, the host disables the UART peripheral, configures the bus I / O to GPIO input mode and enables the 10kΩ pull-down resistor, then reads the bus level five times consecutively (1ms interval). If all readings are high, it confirms that the slave is outputting a high level, and pairing is complete; if a low level is detected, exception handling is triggered. After sending the last authentication response frame, the slave disables the UART peripheral, configures the bus I / O to GPIO push-pull output mode and writes a high level, then the MCU can enter deep sleep (I / O state retained).

[0087] The master only needs to periodically detect the voltage level, while the slave can go into deep sleep, reducing the average power consumption to the microamp level and achieving extremely low power consumption maintenance. After the slave is unplugged, the bus is immediately pulled low by the master's pull-down resistor, and the master can detect the disconnection in the next detection cycle. No heartbeat packet or timed handshake is required, the bus is completely silent, and there is no communication overhead.

[0088] In some implementations, the step of receiving an identity information read instruction from the slave dock and verifying it before replying to the host with an identity response frame includes: the slave dock receiving the identity information read instruction, wherein the identity authentication includes the host's identity ID; obtaining the slave dock's identity ID; combining the host ID and the slave dock's ID into an identity response frame and encrypting it; and sending the encrypted identity response frame to the host.

[0089] Specifically, the host identity ID refers to the unique ID (such as a 4-byte serial number) that identifies the host. It is pre-stored in the host's non-volatile memory and is used by slave devices to identify the host's identity.

[0090] The slave device ID is a unique identifier for the slave device (such as a 4-byte serial number), pre-stored in the slave device's non-volatile memory. Combination refers to concatenating the master ID and slave ID in a pre-defined order (e.g., master ID first, slave ID last) as part of the identity response frame payload.

[0091] For example, the host sends an identity information read command containing the host ID (0xA1B2C3D4) and a random number R3. Upon receiving this command, the slave extracts the host ID and simultaneously reads its own ID (0x5E6F7A8B) from Flash. When constructing the response payload, the slave first writes a 4-byte host ID, then a 4-byte slave ID, followed by R3 (16 bytes), R4 (16 bytes), and identity information (64 bytes), totaling 88 bytes. This is encrypted using AES-128 and sent as an identity response frame. The host decrypts the frame, extracts the returned host ID, and compares it with its own ID. If they match, it continues to verify R3; otherwise, it considers it an attack and resets the connection. Simultaneously, it extracts the returned slave ID and verifies if it is on the authorized whitelist. The slave verifies the host's identity ID to prevent spoofing; the host verifies the slave ID to prevent unauthorized access, achieving two-way authentication. Attackers cannot forge the correct dual ID combination unless they obtain both the host and slave keys, preventing forgery. The host can record paired slave IDs for easier subsequent management and troubleshooting, enabling audit trails.

[0092] Optionally, the host can maintain an "authorized slave ID list" internally, and pairing will only continue if the returned slave ID is in the whitelist. During the initial pairing, the host can assign a temporary ID to the slave, which will be used for subsequent communication.

[0093] The robot base pairing method and system provided by this invention bring the following significant technical advancements and beneficial effects: Achieving extremely low-power connection maintenance: This invention innovatively introduces a "silent ready" state and a "level detection maintenance" mechanism after secure pairing is completed. In this state, the master and slave bases do not require periodic communication handshakes (such as heartbeats) to maintain connection determination. The master only needs to detect the static level very infrequently to know the connection status, making the average communication power consumption of the system close to zero in standby or idle times. This is particularly suitable for battery-powered mobile robot devices, significantly extending battery life.

[0094] An optimal balance between hardware cost and connection reliability is achieved: utilizing only a single-wire communication bus, and through ingenious IO state machine switching, all functions of physical connection detection, bidirectional encrypted communication, and final status confirmation are reused. This eliminates the need for additional dedicated detection pins and circuits, minimizing the cost of connectors and interface circuits. Furthermore, the three-stage verification process of "initial level detection - encrypted data interaction - final level confirmation," especially the final step where the slave device actively outputs a confirmation level and the master device performs filtering and verification, ensures extremely high reliability in connection judgment, effectively avoiding problems such as loose connections and misjudgments caused by contact resistance, environmental interference, or momentary power outages.

[0095] An embedded, lightweight security authentication system was constructed: encrypted authentication and a random number challenge-response mechanism are deeply integrated into the most basic communication link establishment process, achieving "no authentication, no connection." From the PING handshake to the exchange of identity information, this provides a fundamental guarantee for the security management and functional controllability of modular robots.

[0096] It boasts high scalability and engineering friendliness: the protocol adopts a layered, modular design. The basic pairing process is fixed and robust, while the upper-layer instruction set (such as PING, read, and write) and identity information data structure can be flexibly expanded according to product line needs, easily adding advanced functions such as firmware upgrades and parameter configuration. The level detection, state machine, serial port, encryption algorithm, CRC check, etc., on which it relies are all common technologies in the embedded field and can be easily implemented on any MCU with general-purpose I / O, reducing the development threshold and porting cost.

[0097] Enhanced user experience and system robustness: The entire pairing process is automated; users only need to physically plug and unplug the device, and the system can automatically and reliably identify and switch between different functional docks, achieving "plug and play." A robust anomaly handling and state recovery mechanism ensures that in complex electromagnetic environments or under abnormal plugging and unplugging conditions, the system can automatically recover to a known stable state without manual intervention, improving product durability and user experience.

[0098] This application also discloses a split-type robot, such as Figure 1 As shown, a host 100 and a slave dock 200 are connected and communicate with each other via a single-wire communication bus. The host is used to detect the physical connection between the host and the slave dock by configuring their respective ports connected to the single-wire communication bus as input modes. After detecting a successful physical connection, the host switches its own port to serial port transmission mode, sends an authentication command to the slave dock, and switches back to serial port reception mode to wait for a response. After detecting the authentication command, the slave dock switches its own port to serial port transmission mode and sends a response result to the host. The host receives and verifies the response result, completing the two-way handshake authentication with the slave dock.

[0099] Optionally, after the master sends the last stop bit, it needs to wait for a short bus idle time (such as 1-2 bit cycles) before switching to receive mode to ensure that the slave can fully receive the instruction. After the slave receives the last stop bit and processes the instruction, it then switches to transmit mode to respond, in order to avoid bus collisions.

[0100] Specifically, a split-type robot refers to a robot system where the robot body (host) and functional modules (slave bases) can be designed separately. The host can connect to different types of bases (such as walking chassis, robotic arms, charging docks, etc.) to achieve different functions. The host refers to the robot body control unit, which includes a processor, memory, communication interface, and power management circuitry. The slave base refers to the replaceable functional modules, which include a base controller, non-volatile memory (for storing identification information), actuators (motors, sensors, etc.), and communication interface.

[0101] For example, the workflow of this split-type robot is as follows: Initially, the host port is configured in pull-down input mode (10kΩ pull-down resistor connected to GND), and the slave dock port is configured in pull-up input mode (4.7kΩ pull-up resistor connected to 3.3V). When the user inserts the host into the slave dock, the bus voltage jumps from 0V to approximately 2.24V. The host detects a high level after eight consecutive samplings, determining that the physical connection is successful. Subsequently, the host switches to UART transmit mode (115200 8N1), sends an encrypted PING command (containing a 16-byte random number R1), and then switches to UART receive mode. After detecting the falling edge of the start bit, the slave dock switches to UART receive mode, receives and decrypts the command, generates a random number R2, encrypts it, and then switches back to UART transmit mode to reply with a PING response. The host decrypts and compares R1 to complete the two-way handshake. Subsequently, the host sends an identity read command (containing a new random number R3), and the slave dock returns an encrypted identity response frame (containing R3, R4, and identity information). After decryption and verification, the host obtains the identity information and loads the corresponding driver according to the type ID. Finally, the slave device switches to static high-level output, the master device switches back to pull-down input mode and confirms the high level, and pairing is complete. Afterwards, the master device wakes up every 200ms to check the bus level and maintain low-power connection monitoring.

[0102] The slave base should be equipped with an MCU that has fast interrupt response capability, and the processing time of the slave base in the interrupt service routine (including port mode switching and UART receiver enable) should be less than half the duration of the start bit to ensure reliable reception. For example, at a baud rate of 115200, the start bit lasts for about 8.68μs, and the processing time should be less than 4.34μs.

[0103] Optionally, multiple slave docks can be connected in a daisy chain topology between the master and slave docks, and the target can be distinguished by the device ID.

[0104] Optionally, the slave dock can be equipped with a battery management system to report the battery status to the host during pairing. The host can dynamically adapt to the communication protocols of different dock versions through the instruction set version field in the identity information.

[0105] Optionally, the host has an exception logging function, which stores events such as pairing failure and unauthorized access in non-volatile memory for subsequent analysis.

[0106] This modular robot features extremely simplified hardware, requiring only a single wire and two resistors to complete all functions, thus reducing connector costs. It also achieves low-power standby, with the host only periodically checking the voltage level after pairing, while the slave base can enter deep sleep mode. Furthermore, it enables automatic identification and driver loading, automatically recognizing and switching functions after changing to different bases, requiring no user configuration. Security authentication is implemented, preventing unauthorized bases from passing the encrypted handshake and ensuring system security. Finally, it offers plug-and-play functionality, providing a good user experience and requiring no specialized knowledge to operate.

[0107] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0108] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0109] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for pairing split-type robots, characterized in that, Applications include host and slave docks connected via a single-wire communication bus; The method includes: The host and the slave base are configured with their respective ports connected to the single-wire communication bus in input mode to detect the physical connection between them; After detecting a successful physical connection, the host switches its own port to serial port transmission mode, sends an authentication command to the slave dock, and then switches back to serial port reception mode to wait for a response. After detecting the authentication command, the slave device switches its port to serial port transmission mode and sends a response result to the host. The host receives and verifies the response result, completing the two-way handshake authentication with the slave base.

2. The method for pairing split-type robots according to claim 1, characterized in that, The host switches its own port to serial port transmission mode and sends authentication commands to the slave dock, including: The host reconfigures its own port from input mode to serial port transmission mode, and the serial port transmission mode is UART transmission mode; In the UART transmission mode, the host generates and sends authentication commands.

3. The method for pairing split-type robots according to claim 1, characterized in that, The host and the slave dock are configured with their respective ports connected to the single-wire communication bus in input mode to detect the physical connection between them, including: The host computer configures the port connected to the single-wire communication bus to a pull-down input mode. The slave base is configured with the port connected to the single-wire communication bus in pull-up input mode; When the host detects a stable high level on the port, it determines that the host and the slave dock are physically connected and ready.

4. The method for pairing split-type robots according to claim 3, characterized in that, The step of determining that the physical connection between the host and the slave dock is ready when the host detects a stable high level on the port includes: If the host determines that a high level has been detected on the port for a predetermined number of consecutive detection cycles, it determines that the host and the slave base are physically connected and ready.

5. The method for pairing split-type robots according to claim 1, characterized in that, Also includes: After detecting the authentication command, the slave device switches its port to serial port transmission mode and sends a response result to the host, including the following steps: After the slave base detects the falling edge of the start bit, it switches its own port to serial port receiving mode, which is UART receiving mode. After receiving the authentication command, the slave device switches its port to serial port transmission mode and sends the response result to the host.

6. The method for pairing split-type robots according to claim 1, characterized in that, Also includes: The host sends an identity information reading instruction to the slave dock, the identity information reading instruction including a first random number generated by the host; After receiving and verifying the identity information reading instruction, the slave device reads the identity information from its memory, and organizes the first random number, the second random number it generates, and the identity information into an identity response frame, encrypts it, and sends it to the host. The host receives and decrypts the identity response frame, verifies that the first random number is correct, obtains the identity information of the slave dock, and completes identity authentication; After completing identity authentication, the host detects whether the single-wire communication bus is at a high level; If so, the entire pairing process is considered complete; If not, the connection is determined to be abnormal, the host switches its own port back to the drop-down input mode, and resets the communication status to the physical connection detection stage.

7. The method for pairing split-type robots according to claim 6, characterized in that, The identity information reading instruction includes a first random number; The identity response frame includes a first random number, a second random number, and the identity information of the slave device.

8. The method for pairing split-type robots according to claim 6, characterized in that, After the identity authentication step is completed, the following is also included: Switch the single-wire communication bus to drop-down input mode. Switch the slave base communication bus to a static drive mode that continuously outputs a high level.

9. The method for pairing split-type robots according to claim 6, characterized in that, The steps of the slave device receiving the identity information reading command, verifying it, and then replying to the host with an identity response frame include: The slave device receives the identity information reading instruction, and the identity authentication includes the host's identity ID; Obtain the slave docking station identity ID, combine the host ID and the slave docking station ID into an identity response frame and encrypt it; The encrypted identity response frame is sent to the host.

10. A split-type robot, characterized in that, include: A master unit and a slave unit docking station, wherein the master unit is connected and communicates with the slave unit docking station via a single-wire communication bus; The host is configured to detect the physical connection between the host and the slave base by configuring their respective ports connected to the single-wire communication bus as input modes. The host is also used to switch its own port to serial port transmission mode after detecting a successful physical connection, send an authentication command to the slave dock, and switch back to serial port reception mode to wait for a response. The slave dock is used to switch its own port to serial port transmission mode and send a response result to the host after detecting the authentication command; The host is also used to receive and verify the response result, and complete the two-way handshake authentication with the slave base.

Images