Robot firmware and docker image integrated burning method and system
By integrating the Docker environment into the system firmware package, the firmware-level unified burning of robot embedded devices is realized, which solves the problems of low production efficiency, complex processes, and poor deployment consistency, and improves the deployment stability and consistency of the production line.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SUZHOU WANDIANZHANG NETWORK TECH CO LTD
- Filing Date
- 2026-05-11
- Publication Date
- 2026-06-05
AI Technical Summary
In existing technologies, the separate deployment of firmware burning and Docker image for embedded robot devices leads to problems such as low production efficiency, complex processes, and poor production reliability. In particular, the online retrieval and offline import processes are time-consuming, complex, and difficult to guarantee deployment consistency.
By pre-converting the Docker environment into a file system image and integrating it into the system firmware package, the firmware-level unified burning of the system and container environment is achieved. This includes building the Docker image, dividing it into independent partitions, configuring the operating system mount, converting it into a file system image and integrating it into the system firmware image, and finally writing it to the target device all at once.
It enables integrated burning of firmware and container environment, shortens deployment time to about 3 minutes, increases production line throughput, reduces dependence on network and external storage media, ensures deployment stability and consistency, and avoids deployment failure due to network interruption or hardware compatibility issues.
Smart Images
Figure CN122152332A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of embedded device manufacturing technology, and in particular to a method and system for integrating and burning robot firmware with Docker images. Background Technology With the large-scale development of the robotics industry, the production efficiency and deployment consistency of embedded devices have become key factors restricting production capacity. In the production of ARM architecture-based embedded robot systems, system deployment typically adopts a segmented operation mode: first, the basic system firmware is burned into the embedded storage chip, and then the Docker runtime environment and image are installed after the device starts up via network download or import from external storage. This separate deployment operation mode has obvious limitations: low production efficiency. After the system firmware is burned, the Docker image still needs to be pulled online or imported offline on the device. Online pulling takes about 30 minutes, and offline methods also require image loading and decompression. Both methods severely restrict the throughput of the production line. The process is complex. Firmware burning and image installation need to be carried out in stages. It is necessary to add a separate image installation station, increase the time required for operator configuration and testing equipment, and the offline method also requires additional external storage interface resources of the device, affecting the efficiency of process connection. Production reliability is difficult to guarantee. Online installation depends on network bandwidth and the stability of the image repository service. Connection interruption or download failure will directly lead to production stoppage. Offline installation is affected by the read and write speed of storage media and the difference in hardware compatibility. It is difficult to ensure that the Docker environment deployed on each device is completely consistent, and there are hidden dangers in deployment consistency.
[0002] Therefore, there is an urgent need in this field for a method and system for integrating and burning robot firmware with Docker images, which can shorten deployment time, simplify production processes, and improve deployment consistency and stability. Summary of the Invention
[0003] In view of this, the purpose of this invention is to provide a method and system for integrating robot firmware and Docker image burning, so as to solve the problems of low production efficiency, complex procedures and poor production reliability caused by the separate deployment of firmware burning and Docker image in the prior art. By pre-converting the Docker environment into a file system image and integrating it into the system firmware package, the firmware-level integrated burning of the system and container environment is realized, which ensures that the deployment time is shortened, the production process is simplified, the deployment consistency is improved in mass production scenarios, the dependence on network and external storage media is reduced, and the out-of-the-box deployment is completed as soon as the burning is completed.
[0004] The specific plan is as follows: Firstly, this application provides a method for integrating and burning robot firmware with a Docker image, the method mainly including the following steps: S10, build the Docker image; S20, Divide the storage medium of the target platform into independent partitions and configure the operating system to mount the independent partitions; S30, when the target device has deployed the Docker image and the independent partition has stored Docker data, convert the contents of the independent partition into a file system image; S40, Package the file system image and the existing system partition image to generate a system firmware image; S50: Write the system firmware image to the storage medium of the target device in one go, start the target device, and complete the Docker engine loading and image deployment.
[0005] Furthermore, the process of building the Docker image includes: writing dependency libraries, function packages, and configuration files into a Docker file to build a Docker image with a specified architecture; and after the image is built, pushing it to a private image repository or compressing and exporting it as an archive file.
[0006] Furthermore, the step of dividing the independent partition and configuring the operating system to mount the independent partition includes: adjusting the partition layout, adding a new partition and setting its capacity and file system format; modifying the mount configuration file and adding a mount entry for the independent partition; and modifying the Docker service configuration to point the data root directory to the mount point of the independent partition.
[0007] Furthermore, the format of the file system image is consistent with the file system format of the independent partition, and the operating system directly mounts the partition corresponding to the file system image after the target device boots up.
[0008] Furthermore, converting the contents of the independent partition into a file system image includes: calculating additional margin and adding redundant capacity based on the data size of the directory and the number of file nodes in the independent partition, and determining the image size.
[0009] Furthermore, the step of converting the contents of the independent partition into a file system image also includes: using a file system creation tool to convert the data in the independent partition into a file system image according to the image size; after generating the file system image, disabling automatic file system checks triggered based on the number of mounts and based on time intervals using a file system tuning tool.
[0010] Furthermore, the packaging of the file system image and the existing system partition image includes: generating a system firmware image in a unified format by combining the file system image, the bootloader image, the kernel image, and the root file system image according to the partition table information using a firmware packaging tool.
[0011] Furthermore, the step of writing the system firmware image to the storage medium of the target device in one go includes: after the device enters the firmware download mode, loading the system firmware image and performing a one-time write, and writing all the data of all partitions in the image to the embedded storage chip.
[0012] Furthermore, starting the target device and completing Docker engine loading and image deployment includes: after the target device starts, the operating system automatically mounts the independent partition according to the mounting configuration, and the Docker engine loads the pre-set image data from the independent partition.
[0013] Secondly, this application provides a robot firmware and Docker image integration and burning system for implementing the robot firmware and Docker image integration and burning method as described above. The system includes an image building module, a partition configuration module, an image conversion module, a firmware integration module, and a mass production burning module. The image building module is used to build Docker images; The partition configuration module is used to divide the storage medium of the target platform into independent partitions and configure the operating system to mount the independent partitions. The image conversion module is used to convert the contents of the independent partition into a file system image when the target device has deployed the Docker image and the independent partition has stored Docker data. The firmware integration module is used to package the file system image and the existing system partition image to generate a system firmware image; The mass production burning module is used to write the system firmware image to the storage medium of the target device in one go, start the target device, and complete the Docker engine loading and image deployment.
[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) By converting the independent partition content of the deployed Docker data into a file system image and integrating it with the existing system partition images such as the bootloader, kernel, and root file system into a unified system firmware image, the firmware-level integrated burning of the firmware and container environment is realized. The original phased firmware burning and Docker image installation are integrated into a one-time burning operation, reducing the deployment time to about 3 minutes and improving the throughput of the production line.
[0015] (2) By pre-solidifying the Docker environment into the firmware image, the mass production burning process does not need to rely on network connection for online pulling, eliminating the risk of production interruption due to network bandwidth fluctuations or unstable image source, and ensuring the continuity and stability of production.
[0016] (3) The system and container environment can be fully deployed by burning the program once, avoiding operations such as copying files on the device, downloading from the network and importing from external storage media offline. This reduces the risk of deployment failure due to transmission interruption or hardware compatibility issues. At the same time, the independent image installation process is eliminated, reducing the number of operators and the occupation of testing equipment, and reducing the overall manufacturing cost. Attached Figure Description
[0017] 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 embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0018] Figure 1 A flowchart illustrating a method for integrating and burning robot firmware with a Docker image, as provided in an embodiment of the present invention; Figure 2 A structural block diagram of a robot firmware and Docker image integration and burning system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention; Figure 4 This is another structural schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0019] The present invention will be further described in detail below with reference to a specific application embodiment and accompanying drawings. This embodiment is implemented based on the technical solution of the present invention, and provides detailed implementation methods and specific operation processes, but the scope of protection of the present invention is not limited to the following embodiment.
[0020] Example 1 Please see Figure 1 This invention provides a technical solution: a method for integrating and burning robot firmware with a Docker image. Specifically, it includes the following steps: S10, build Docker image.
[0021] S101 uses Dockerfile to write dependency libraries, function packages, and configuration files to build and generate Docker images with a specified architecture.
[0022] S102, after the build is complete, push the image to a private image repository or compress and export it as an archive file.
[0023] In a specific application scenario, developers build Docker images on a Linux development host. First, a Dockerfile is written, based on the official ROS base image. The Dockerfile defines the necessary dependencies for the robot application, custom ROS packages, startup scripts, and environment configuration files. Since the target device uses an ARM64 architecture, Docker's cross-platform build capabilities are utilized. The `docker buildx build` command specifies the platform as `linux / arm64`, generating a Docker image suitable for the target device's architecture. The completed image is approximately 5GB in size. After the image is built, to facilitate subsequent deployment to the target device, the image can be pushed to a private image repository on the local network using the `docker push` command, allowing the target device to pull it directly in subsequent steps. Alternatively, the `docker save` command, combined with compression tools, can export the image as a compressed archive file for offline transfer via external storage media.
[0024] S20: Divide the target platform's storage medium into independent partitions and configure the operating system to mount the independent partitions.
[0025] S201, Adjust partition layout, add new partitions and set capacity and file system format.
[0026] S202, Modify the mount configuration file and add a mount entry for the aforementioned independent partition.
[0027] S203, Modify the Docker service configuration to point the data root directory to the mount point of the independent partition.
[0028] In specific application scenarios, the storage partitioning scheme of the target platform needs to be customized. The target platform uses embedded storage chips as the main storage medium, with a total capacity of 64GB. Using the partition table configuration tool provided by the platform vendor, the platform's partition table file is opened. Based on the existing boot, rootfs, and data partition structures, a new independent partition is added specifically for storing Docker data, named the docker partition. This partition's capacity is set to 24GB, and the file system format is specified as ext4. After the partitioning scheme is determined, the system configuration in the root file system needs to be modified synchronously to ensure that the new partition is correctly mounted when the system starts. Specifically, the mount configuration file in the rootfs root file system is modified, adding a mount record for the docker partition. The configuration content is to mount the partition labeled docker to the / docker directory, with the file system type as ext4. Mount options include parameters such as sync, noatime, nodiratime, and barrier=1. The sync and noatime mount options ensure the timeliness of data writing and access performance. Simultaneously, to ensure the Docker engine stores data on this independent partition instead of the default system partition, the Docker service configuration file in the rootfs root file system needs to be modified, setting the data-root parameter to / docker. This points the Docker data storage root directory to the mount point of this partition. After completing the above configuration modifications, the updated partition table is integrated with the existing uboot.img, boot.img, rootfs.img, and other partition images using the platform firmware packaging tool to generate the base system firmware image update_base.img. This firmware image has completed the reservation of Docker partitions and system mounting configuration, but does not yet contain any Docker image data.
[0029] S30, when the target device has deployed the Docker image and the independent partition has stored Docker data, the contents of the independent partition are converted into a file system image.
[0030] S301, based on the data size of the directory and the number of file nodes in the independent partition, calculate the extra margin and add redundant capacity to determine the image size.
[0031] S302, using a file system creation tool, the data under the independent partition mount point is converted into a file system image according to the image size. The format of the file system image is consistent with the file system format of the independent partition. After the target device starts up, the operating system directly mounts the partition corresponding to the file system image.
[0032] S303, after generating the file system image, disable automatic file system checks triggered by the number of mounts and by the time interval using the file system tuning tool.
[0033] In specific application scenarios, this step is the core conversion process of this invention. First, the basic system firmware image update_base.img with a reserved Docker partition is burned to the embedded storage chip of the target board using a burning tool, and the device is then started. After the device starts, according to the aforementioned partition configuration and mount settings, the Docker data root directory points to the / docker partition. At this time, the previously built Docker image is pulled online from the private image repository using the docker pull command, or loaded from an external storage medium offline. Regardless of the method used, after pulling or loading, all layer data and container metadata of the Docker image are stored in the / docker partition directory. Next, the complete data in the / docker partition needs to be converted into an independent file system image for subsequent packaging and integration. First, the image size needs to be determined: the actual data space occupied by the / docker directory is obtained using the du command, and the number of file nodes in the directory is counted using the find command. The two are then calculated using a formula, with each file node estimated with an additional 4KB of margin. After obtaining the basic data volume, to ensure sufficient free space during subsequent operation, redundant capacity is added at a rate of 10%, resulting in the final image size. Once the image size is determined, a file system creation tool is used to perform the conversion operation. The command converts the entire contents of the ` / docker` directory into an ext4 format file system image, `docker.img`, specifying the source directory as ` / docker`, the block size as 4KB, and ensuring the image file system format matches the ` / docker` partition. After the conversion, to prevent time-consuming automatic file system checks from being triggered during mass production due to abnormal shutdowns or other anomalies, parameters in the generated `docker.img` are optimized using a file system tuning tool: the maximum mount count trigger threshold and the check interval trigger threshold are set to 0, thus disabling the automatic file system check mechanism based on mount count and time interval.
[0034] S40, Package the file system image and the existing system partition image to generate a system firmware image.
[0035] S401, the file system image, bootloader image, kernel image, and root file system image are combined according to the partition table information and a unified format system firmware image is generated using a firmware packaging tool.
[0036] In specific application scenarios, this step integrates the outputs of the preceding steps. The modified partition table file is used as the basis for partition layout; this partition table defines the location, capacity, and file system format of the Docker partitions. The generated file system image docker.img is used as the image file corresponding to the Docker partition, and placed in the same working directory as the existing partition images uboot.img, boot.img, rootfs.img, etc. Using a firmware packaging tool, each partition image is packaged into a firmware image file according to the partition definition in the partition table, and then encapsulated into the platform's standard firmware upgrade format, ultimately generating a complete, programmable system firmware image named update_final.img. This firmware image, in addition to containing the bootloader, operating system kernel, and root file system, also embeds a complete Docker runtime environment and pre-installed ROS container image data.
[0037] S50: Write the system firmware image to the storage medium of the target device in one go, start the target device, and complete the Docker engine loading and image deployment.
[0038] S501: After the device enters the firmware download mode, it loads the system firmware image and performs a one-time write, writing all the data of all partitions in the image completely into the embedded storage chip.
[0039] S502, after the target device starts, the operating system automatically mounts the independent partition according to the mounting configuration, and the Docker engine loads the preset image data from the independent partition.
[0040] In specific application scenarios, this step completes the final deployment on the factory mass production line. The operator connects the motherboard of the robot device to be programmed to the production host computer via a data cable, and enters the firmware download mode by shorting or pressing a button, putting the device in a firmware download-ready state. The host computer starts the programming tool, enters the firmware upgrade function page, loads the integrated and generated complete firmware image update_final.img, and the tool parses and displays the partition information contained in the image. After starting the programming operation, the programming tool distributes the data of all partitions in the firmware image one by one via the USB protocol and writes it to the corresponding physical address of the device's embedded storage chip. The programming process for a single device takes approximately 3 minutes. After programming is complete, the device automatically restarts and enters the system initialization process. During the operating system kernel startup process, according to the pre-configured mount entries in the mount configuration file, the kernel automatically identifies the partition label of the Docker partition in the embedded storage chip and mounts it to the / docker directory as an ext4 file system. After the system enters user space, the Docker daemon starts and loads all pre-configured Docker image layer data and container metadata from the / docker directory according to the data-root parameter in the Docker service configuration file. The entire loading process is completed automatically during the system startup phase. After the device has started up, the user can directly use the complete ROS runtime environment without any additional operation, achieving an out-of-the-box deployment effect of burning and completing the process.
[0041] Accordingly, see Figure 2 As shown, this application also provides a robot firmware and Docker image integration and burning system, used to implement the robot firmware and Docker image integration and burning method as described above. The system includes an image building module, a partition configuration module, an image conversion module, a firmware integration module, and a mass production burning module. The image building module is used to build Docker images; The partition configuration module is used to divide the storage medium of the target platform into independent partitions and configure the operating system to mount the independent partitions. The image conversion module is used to convert the contents of the independent partition into a file system image when the target device has deployed the Docker image and the independent partition has stored Docker data. The firmware integration module is used to package the file system image and the existing system partition image to generate a system firmware image; The mass production burning module is used to write the system firmware image to the storage medium of the target device in one go, start the target device, and complete the Docker engine loading and image deployment.
[0042] Accordingly, this application also provides an electronic device and a computer-readable storage medium, both of which have the corresponding effects of the robot firmware and Docker image integration and burning method provided in the embodiments of this application. Please refer to... Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0043] An electronic device provided in this application includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the robot firmware and Docker image integration and burning method described in the above embodiment.
[0044] Please see Figure 4 Another electronic device provided in this application embodiment further includes: an input port connected to a processor for transmitting commands input from the outside to the processor; a display unit connected to the processor for displaying the processor's processing results to the outside; and a communication module connected to the processor for enabling communication between the electronic device and the outside. The display unit can be a display panel, a laser scanner, or the like; the communication method used by the communication module includes, but is not limited to, Mobile High-Definition Link (MHL), Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), wireless connectivity: Wireless Fidelity (WiFi), Bluetooth communication technology, Bluetooth Low Energy communication technology, and communication technology based on IEEE 802.11s.
[0045] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the robot firmware and Docker image integration and burning method described in any of the above embodiments.
[0046] The computer-readable storage media involved in this application include random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs (compact disc read-only memory), or any other form of storage media known in the art.
[0047] In summary, this invention pre-builds a Docker image and stores Docker data in an independent partition on the target platform. It then converts the contents of this independent partition into a file system image, achieving firmware-level integration and one-time flashing of the Docker environment and the existing system partition image. Combined with the operating system automatically mounting the independent partition after device startup and the Docker engine automatically loading the pre-built image data, this invention completes the integrated deployment of firmware and container environments, simplifies the mass production flashing process, and delivers a complete, ready-to-use system. This solves the problems of low production efficiency, complex procedures, and poor deployment consistency inherent in traditional separate firmware flashing and Docker image deployment. It shortens device production and deployment time, improves production line throughput and deployment consistency, and ensures deployment stability and reliability in mass production scenarios.
[0048] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.
[0049] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A method for integrating and burning robot firmware with a Docker image, characterized in that, Includes the following steps: S10, build the Docker image; S20, Divide the storage medium of the target platform into independent partitions and configure the operating system to mount the independent partitions; S30, when the target device has deployed the Docker image and the independent partition has stored Docker data, convert the contents of the independent partition into a file system image; S40, Package the file system image and the existing system partition image to generate a system firmware image; S50: Write the system firmware image to the storage medium of the target device in one go, start the target device, and complete the Docker engine loading and image deployment.
2. The method for integrating and burning robot firmware with a Docker image according to claim 1, characterized in that, The step S10 of building a Docker image includes: writing dependency libraries, function packages and configuration files through a Dockerfile to build a Docker image with a specified architecture; after the image is built, pushing it to a private image repository or compressing and exporting it as an archive file.
3. The method for integrating and burning robot firmware with a Docker image according to claim 1, characterized in that, Step S20, which involves dividing the partition into independent partitions and configuring the operating system to mount the independent partitions, includes: adjusting the partition layout, adding a new partition and setting its capacity and file system format; modifying the mount configuration file and adding a mount entry for the independent partition; and modifying the Docker service configuration to point the data root directory to the mount point of the independent partition.
4. The method for integrating and burning robot firmware with a Docker image according to claim 1, characterized in that, In step S30, the format of the file system image is consistent with the file system format of the independent partition, and the operating system directly mounts the partition corresponding to the file system image after the target device starts up.
5. The method for integrating and burning robot firmware with a Docker image according to claim 1, characterized in that, In step S30, converting the contents of the independent partition into a file system image includes: calculating additional margin and adding redundant capacity based on the data size of the directory and the number of file nodes in the independent partition, and determining the image size.
6. The method for integrating and burning robot firmware with a Docker image according to claim 5, characterized in that, The step S30 of converting the contents of the independent partition into a file system image further includes: using a file system creation tool to convert the data in the independent partition into a file system image according to the image size; after generating the file system image, disabling automatic file system checks triggered by the number of mounts and by the time interval through a file system tuning tool.
7. The method for integrating and burning robot firmware with a Docker image according to claim 1, characterized in that, The step S40 of packaging the file system image and the existing system partition image includes: generating a system firmware image in a unified format by combining the file system image, the bootloader image, the kernel image, and the root file system image according to the partition table information using a firmware packaging tool.
8. The method for integrating and burning robot firmware with a Docker image according to claim 1, characterized in that, Step S50, which involves writing the system firmware image to the storage medium of the target device in one go, includes: after the device enters the firmware download mode, loading the system firmware image and performing a one-time write operation, and writing all the data of all partitions in the image to the embedded storage chip.
9. The method for integrating and burning robot firmware with a Docker image according to claim 1, characterized in that, Step S50, which involves starting the target device and completing Docker engine loading and image deployment, includes: after the target device starts, the operating system automatically mounts the independent partition according to the mounting configuration, and the Docker engine loads the pre-set image data from the independent partition.
10. A robot firmware and Docker image integration and burning system, used to implement the method as described in any one of claims 1 to 9, characterized in that, The system includes an image building module, a partition configuration module, an image conversion module, a firmware integration module, and a mass production burning module. The image building module is used to build Docker images; The partition configuration module is used to divide the storage medium of the target platform into independent partitions and configure the operating system to mount the independent partitions. The image conversion module is used to convert the contents of the independent partition into a file system image when the target device has deployed the Docker image and the independent partition has stored Docker data. The firmware integration module is used to package the file system image and the existing system partition image to generate a system firmware image; The mass production burning module is used to write the system firmware image to the storage medium of the target device in one go, start the target device, and complete the Docker engine loading and image deployment.