Lightweight Ubuntu system cutting method and system oriented to RISCV architecture and supporting ROS2
By identifying and tagging core ROS2 components and removing irrelevant software packages and static files, the resource consumption problem of ROS2 on RISCV edge devices is solved, and a stable, reliable and reproducible trimming scheme for a lightweight Ubuntu system is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-31
- Publication Date
- 2026-04-07
AI Technical Summary
Existing technologies lack a deep customization solution for RISCV hardware platforms, Ubuntu base systems, and ROS2 application frameworks when deploying ROS2 on resource-constrained RISCV edge devices. This results in slow system startup, excessive resource consumption, and a lack of precision and reproducibility in the customization process, which can easily lead to the accidental deletion of critical components and affect system stability.
By identifying the core system components required for ROS2 to run, marking them as manually installed, trimming packages and static files unrelated to ROS2, performing deep trimming of the system image using automated tools, and verifying stability through ROS2 core communication functions, a lightweight Ubuntu system image is generated.
It achieves precise and in-depth trimming of the system image, ensuring the integrity of ROS2 core functions, system stability and reliability, while lowering the technical threshold and improving the reproducibility and scalability of the trimming process.
Smart Images
Figure CN121807368A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a method and system for tailoring a lightweight Ubuntu system for RISC-CV architecture and supporting ROS2, belonging to the field of embedded operating system optimization technology. Background Technology
[0002] With the rapid development of robotics and edge computing, ROS2 has become the mainstream framework for robot software due to its distributed and real-time characteristics. The RISC-CV architecture, with its open, streamlined, and efficient features, has shown great potential in embedded and edge applications. However, deploying ROS2 on resource-constrained RISC-CV edge devices (such as the Banana Pi BPI-F3) presents significant challenges.
[0003] Standard Ubuntu server or desktop versions are bulky, containing numerous packages, services, and documentation unrelated to ROS2 operation. This consumes valuable storage and memory resources, leading to slow boot times, which contradicts the stringent requirements of edge devices for lightweight, efficient, and fast startup. Currently, while there are general methods for minimizing system installations, there is a lack of a systematic, deeply tailored solution for the specific combination of "RISC-V hardware platform + Ubuntu base system + ROS2 application framework." Existing methods often suffer from the following problems: 1. Blindly cutting out components: The lack of accurate identification of core ROS2 dependencies can easily lead to the accidental deletion of critical system components (such as specific network configuration tools, system services or underlying libraries), resulting in abnormal ROS2 communication functions or system instability.
[0004] 2. Incomplete trimming: Only superficial package management operations are performed, without thoroughly cleaning up redundant static files (such as documents, fonts, and localization files) within the system, resulting in limited size reduction.
[0005] 3. Lack of reproducibility: The cutting process relies on human experience, making it difficult to form a standardized process, which is not conducive to the reuse and promotion of the results.
[0006] Therefore, there is an urgent need in this field for a technical solution that can accurately, deeply, and automatically tailor the Ubuntu system to make it a minimal operating baseline optimized for ROS2 on the RISCV platform. Summary of the Invention
[0007] To address the shortcomings of existing technologies, this invention provides a method and system for tailoring a lightweight Ubuntu system for the RISC-CV architecture and supporting ROS2. This method minimizes the system image size while ensuring the integrity and stable operation of the core ROS2 functions. Furthermore, the lightweight Ubuntu system image obtained through the above method can be combined with its accompanying reproducible toolchain to form a reproducible system tailoring toolkit.
[0008] Terminology Explanation: 1. Ubuntu: An open-source Linux operating system based on Debian, maintained by Canonical and widely used in personal computers, servers, and embedded devices.
[0009] 2. RISCV: An open-source instruction set architecture (ISA) based on the Reduced Instruction Set Computing (RISC) principle, developed by the University of California, Berkeley, and characterized by its openness, modularity, and efficiency.
[0010] 3. ROS2: Robot Operating System 2 is an open-source operating system framework designed specifically for robot software development. It supports distributed, real-time communication and is widely used in robot software development.
[0011] 4. ROS2 Humble: A Long Term Support (LTS) release of ROS2, released in 2022, supporting Ubuntu 22.04.
[0012] 5. DDS (Data Distribution Service): A high-performance middleware protocol that allows data producers (publishers) and consumers (subscribers) to communicate directly without the need for an intermediary.
[0013] 6. apt: This is the command-line package management tool for Debian and its derivative Linux distributions. It was created by the Debian development team based on the dpkg system and is used to solve software dependency and automated maintenance problems. It supports package installation, updates, uninstallation and dependency management functions.
[0014] The technical solution of the present invention is as follows: The first aspect of this invention provides a method for tailoring a lightweight Ubuntu system for RISC-CV architecture and supporting ROS2, comprising: Step 1: Obtain the original Ubuntu system image based on the RISCV architecture, install ROS2 in the original Ubuntu system image, and mark the core system components required for ROS2 to run as manually installed. Step 2: Remove packages that are not relevant to ROS2 operation from the original Ubuntu system image marked as manual installation; Step 3: Deploy the standard test node software package and verify the communication functionality of ROS2; If communication is normal, proceed to step 4; otherwise, return to step 2. Step 4: Trim non-essential static files from the system directory of the original Ubuntu system image; Step 5: Trim redundant software components and clean up system logs. Compress the system disk contents of the trimmed original system image into an image file to obtain a lightweight Ubuntu system.
[0015] According to a preferred embodiment of the present invention, the core system components required for ROS2 operation are marked as manually installed; including: In the original system image, the core system components required for ROS2 to run include the networkd-dispatcher package responsible for network status management, the network configuration tools netplan.io and netplan-generator, the network command set iproute2, the system information tool lsb-release, the system service compatibility layer systemd-sysv, the compiler runtime library gcc-13-base, the kernel management package linux-base, the network communication libraries libnl-3-200, libnl-genl-3-200, libnl-route-3-200, the JSON parsing library libjansson4, and the compression tool zstd; Use the package management tool apt to execute the installation status command to mark the core system components required for ROS2 to run as manually installed.
[0016] According to a preferred embodiment of the present invention, step 2 specifically comprises: Use the package management tool apt to execute the uninstall command to actively uninstall packages from the original system image that are not related to ROS2 operation, including: Log rotation tool logrotate, system log service rsyslog, console setup console-setup, keyboard configuration keyboard-configuration, keyboard layout data xkb-data, Vim editor common files vim-common, kernel header files linux-headers-*, Z-shell tool zsh, Z-shell common files zsh-common, hexadecimal viewer xxd, file viewer less, dialog box tool whiptail, Wi-Fi connection tool wpasupplicant, disk partitioning tool fdisk, eject device tool eject, localization support locales, internationalization configuration debconf-i18n, MIME type database shared-mime-info, binary toolset binutils, initramfs tool dracut-install, utilities sensible-utils, initramfs tool initramfs-tools-bin, D-Bus user session dbus-user-session, klibc tools klibc-utils*, klibc library libklibc*, man pages.
[0017] According to a preferred embodiment of the present invention, deploying a standard test node software package and verifying the communication functionality of ROS2 includes: Install the standard test node packages for ROS2 Humble in the original system image, including the C++ version of the demo node package ros-humble-demo-nodes-cpp and the Python version of the demo node package ros-humble-demo-nodes-py. In two separate terminal windows, run the talker node and listener node from the standard test node package respectively to verify whether the communication function between the talker and listener nodes is normal, i.e., observe the output of the two terminal windows. If the terminal window running the talker node continuously outputs the published message content, and the terminal window running the listener node synchronously outputs the received message, then the communication is considered to be normal, that is, the publish / subscribe communication mechanism based on DDS in ROS2 is working normally, and the pruning has not damaged the core ROS2 operating environment. If any test node fails to start, exit, or display the expected output, it is considered a communication anomaly.
[0018] According to a preferred embodiment of the present invention, step 4 specifically comprises: Manually delete all contents of static files in the system directory that take up a lot of space but are not related to operation, or keep only some files in the static files as needed; Static files include: document directory, information directory, manual directory, localization file directory, font directory, log directory, and cache directory.
[0019] Further optimization, in ROS2 embedded application scenarios that pursue ultimate trimming, delete all static files, including document formatting tool files, bash auto-completion files, Vim editor files, internationalization files, Thai support files, Deb package checking tool files, Perl modules, public suffix lists, XML data, JavaScript libraries, X Window system files, fault reporting tools, GCC related files, C++ test framework files, aclocal data, error reporting tools, documentation basics, GDB debugger files, graphical visualization tools, initramfs tools, menu definitions, icon files, pkg-config files, policy toolkits, utilities, SGML data, SGML basics, tab settings, Valgrind tools, Aptitude package manager data, DHCP client data, and color management data.
[0020] According to a preferred embodiment of the present invention, step 5 specifically comprises: The automated cleanup command `sudo apt autoremove --purge` automatically identifies and removes orphaned packages, and also completely removes the configuration files corresponding to orphaned packages. Orphaned packages include those that were automatically installed due to dependencies and are no longer depended on by any packages marked as manually installed in the current system state. Execute the system log cleanup command `sudo journalctl --vacuum-time=1s` to clean up the structured log file, deleting all old log entries whose recording time exceeds the set time, and only keeping the latest logs generated within the most recent set time. Use a disk imaging tool to export the trimmed system disk contents from the original system image as an img file, and then use a compression tool to compress it to generate a system image file, resulting in a lightweight Ubuntu system.
[0021] A computer device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement steps of a lightweight Ubuntu system tailored for a RISCV architecture.
[0022] A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the steps of a method for tailoring a lightweight Ubuntu system for a RISC-CV architecture.
[0023] A second aspect of the present invention provides a lightweight Ubuntu system tailored for RISC-CV architecture and supporting ROS2, comprising: The manual installation status marking module is configured to: obtain the Ubuntu raw system image based on the RISCV architecture, install ROS2 in the Ubuntu raw system image, and mark the core system components required for ROS2 to run as manually installed. The irrelevant package trimming module is configured to trim packages that are irrelevant to ROS2 operation from the Ubuntu raw system image marked as manual installation. The communication function verification module is configured to: deploy the standard test node package and verify the communication function of ROS2; if the communication is normal, execute the static file trimming module; otherwise, return to the step-independent package trimming module. The static file trimming module is configured to trim non-essential static files in the system directory of the original Ubuntu system image. The Ubuntu system generation module is configured to: trim redundant software components and clean up system logs, compress the system disk contents of the trimmed original system image into an image file, and obtain a lightweight Ubuntu system.
[0024] The beneficial effects of this invention are as follows: 1. Accuracy and Reliability: By pre-identifying and locking the critical system components necessary for ROS2 operation, the system's functionality is fundamentally prevented from being damaged or ROS2 communication failed due to accidental deletion of dependencies, thus ensuring the stability and reliability of the trimmed system.
[0025] 2. Deep Minimization: Combining package-level trimming and file-level deep cleanup, it not only removes redundant software packages but also clears static documents, logs, and caches that occupy a lot of space, achieving extreme compression of system size (approximately 456MB after compression), far exceeding the effect of conventional minimal installation.
[0026] 3. Functional completeness: Real-time verification of the core ROS2 communication function (DDS) serves as a "safety valve" for the trimming process, ensuring that each trimming operation does not affect the operation of the core application, ultimately resulting in a fully functional lightweight ROS2 application platform.
[0027] 4. Reproducibility and Scalability: The tailoring process is scripted and documented, and the kernel and ROS2 source code are provided, forming a complete and reproducible technical system. This greatly lowers the technical barrier to deploying and customizing lightweight ROS2 systems on similar RISC-CV edge devices, which is conducive to the promotion of the technology and the construction of the ecosystem. Attached Figure Description
[0028] Figure 1 This is the overall flowchart of the lightweight Ubuntu system tailoring method for the RISC-CV architecture of this invention. Detailed Implementation
[0029] The present invention will be further described below with reference to the embodiments and accompanying drawings, but is not limited thereto.
[0030] Example 1 A lightweight Ubuntu system tailored for RISC-CV architecture and supporting ROS2, such as... Figure 1 As shown, it includes: Step 1: Obtain the original Ubuntu system image based on the RISCV architecture, install ROS2 in the original system image, and mark the core system components required for ROS2 to run as manually installed. Step 2: Remove software packages that are not relevant to ROS2 operation from the original system image; Step 3: Deploy the standard test node software package and verify the communication functionality of ROS2; If communication is normal, proceed to step 4; otherwise, return to step 2 to ensure that the ROS2 core runtime environment remains intact and usable after each trimming operation. Step 4: Trim non-essential static files from the system directory; Step 5: Trim redundant software components and clean up system logs. Compress the system disk contents of the trimmed original system image into an image file to obtain a lightweight Ubuntu system.
[0031] Example 2 The difference between the lightweight Ubuntu system tailored for RISC-CV architecture and supporting ROS2 described in Example 1 and the following is: Download the Ubuntu minimal system image based on the RISCV architecture from the official website, such as the bianbu-24.04-minimal-k1-v2.2-release-20250430181626.img file released by Advance Space; this image is the original base system built specifically for the RISCV K1 platform (such as the BPI-F3 development board); Mark the core system components required for ROS2 to run as manually installed; including: In the original system image, the core system components required for ROS2 to run include the networkd-dispatcher package responsible for network status management, the network configuration tools netplan.io and netplan-generator, the network command set iproute2, the system information tool lsb-release, the system service compatibility layer systemd-sysv, the compiler runtime library gcc-13-base, the kernel management package linux-base, the network communication libraries libnl-3-200, libnl-genl-3-200, libnl-route-3-200, the JSON parsing library libjansson4, and the compression tool zstd; Use the package management tool apt to execute the installation status command `sudo apt-mark manual <package name list>` to mark the core system components required for ROS2 to run as manually installed, in order to prevent subsequent automated cleanup commands from accidentally deleting these components.
[0032] Step 2 is as follows: Use the package management tool apt to execute the uninstall command `sudo apt purge <package name list>` to actively uninstall packages from the original system image that are not related to ROS2 operation, including: Log rotation tool logrotate, system log service rsyslog, console setup console-setup, keyboard configuration keyboard-configuration, keyboard layout data xkb-data, Vim editor common files vim-common, kernel header files linux-headers-*, Z-shell tool zsh, Z-shell common files zsh-common, hexadecimal viewer xxd, file viewer less, dialog box tool whiptail, Wi-Fi connection tool wpasupplicant, disk partitioning tool fdisk, eject device tool e The following packages are not required in a pure ROS2 application scenario: ject, locales (localization support), debconf-i18n (internationalization configuration), shared-mime-info (MIME type database), binutils (bin utility set), dracut-install (initramfs tool), sensible-utils (utility tool), initramfs-tools-bin (initramfs tool), dbus-user-session (D-Bus user session), klibc-utils* (klibc tools), libklibc* (klibc library), and manpages.
[0033] Deploy the standard test node software package and verify the communication functionality of ROS2; including: Install the standard test node packages for ROS2 Humble in the original system image (installed via the system package manager), including the C++ version of the demo node package ros-humble-demo-nodes-cpp and the Python version of the demo node package ros-humble-demo-nodes-py. These packages are deployed to the system global directory / opt / ros / humble using the sudo apt install command. In two separate terminal windows (two command-line windows running simultaneously in the original system image), run the talker node (a publisher node written in C++ that periodically publishes string messages) and the listener node (a subscriber node written in Python that subscribes to and echoes received messages) from the standard test node package, respectively, to verify whether the communication function between the talker and listener nodes is normal, that is, observe the output of the two terminal windows (execute the commands ros2 run demo_nodes_cpp talker and ros2 run demo_nodes_pylistener in the two terminal windows respectively). If the terminal window running the talker node continuously outputs published message content (such as the "Publishing: 'Hello World:'" series of messages), and the terminal window running the listener node synchronously outputs received messages (such as the "Iheard: [Hello World:]" series of messages), then the communication is considered normal, that is, the DDS-based publish / subscribe communication mechanism in ROS2 is working normally, and the pruning has not damaged the core ROS2 operating environment. If any test node fails to start, exit, or display the expected output, it is considered a communication anomaly.
[0034] Step 4 specifically involves: Manually delete all contents of static files in the system directory that take up a lot of space but are not related to operation, or keep only some files in the static files as needed (e.g., to maintain a basic English environment, you can keep the relevant subdirectories such as / usr / share / locale / en and / usr / share / locale / en_US in the localization file directory). Static files include: the documentation directory ( / usr / share / doc / ), the information directory ( / usr / share / info / ), the manual directory ( / usr / share / man / ), the localization file directory ( / usr / share / locale / ), the font directory ( / usr / share / fonts / ), the log directory ( / var / log / ), and the cache directory ( / var / cache / ).
[0035] In ROS2 embedded applications where extreme minimalism is desired, deleting all static files includes removing the following from the system directory: document formatting tool file ( / usr / share / groff), bash auto-completion file ( / usr / share / bash-completion), Vim editor file ( / usr / share / vim), internationalization file ( / usr / share / i18n), Thai support file ( / usr / share / libthai), Deb package checker file ( / usr / share / lintian), Perl module ( / usr / share / perl5), public suffix list ( / usr / share / publicsuffix), XML data ( / usr / share / xml), JavaScript library ( / usr / share / javascript), and X. Windows system files ( / usr / share / X11), bug reporting tool ( / usr / share / bug), GCC related files ( / usr / share / gcc), C++ test framework files ( / usr / share / Catch2), aclocal data ( / usr / share / aclocal), error reporting tool ( / usr / share / apport), documentation base ( / usr / share / doc-base), GDB debugger files ( / usr / share / gdb), graphical visualization tools ( / usr / share / graphviz), initramfs tools ( / usr / share / initramfs-tools), menu definitions ( / usr / share / menu), icon files ( / The database includes: usr / share / pixmaps, pkg-config file ( / usr / share / pkgconfig), policy toolkit ( / usr / share / polkit-1), utilities ( / usr / share / sensible-utils), SGML data ( / usr / share / sgml), SGML basics ( / usr / share / sgml-base), tab settings ( / usr / share / tabset), Valgrind utility ( / usr / lib / valgrind), Aptitude package manager data ( / var / lib / aptitude), DHCP client data ( / var / lib / dhclient), and color management data ( / var / lib / colord).
[0036] Step 5 specifically involves: The automated cleanup command `sudo apt autoremove --purge` operates on the entire system's package management system, automatically identifying and removing orphaned packages, and thoroughly cleaning up their corresponding configuration files. Orphaned packages include those that were automatically installed due to dependencies and are no longer depended on by any packages marked as manually installed in the current system state. This operation primarily cleans up the system's ` / var / lib / dpkg` and ` / var / lib / apt` databases, as well as the installation directories of various packages (such as ` / usr`, ` / etc`, etc.), aiming to clean up residual software entities and configurations, further freeing up storage space. The system log cleanup command `sudo journalctl --vacuum-time=1s` cleans up the structured log files (maintained by the systemd journaling system and usually stored in the ` / var / log / journal / ` directory). It deletes all old log entries whose recording time exceeds the set time (1s) and only retains the latest logs generated within the most recent set time (1s), thereby significantly reducing the system logs' occupation of persistent storage. Through these two cleanup steps, the system can remove redundant software components and clear unnecessary runtime log data, maximizing the reclamation of storage space. Use a disk imaging tool (such as the dd command) to export the trimmed system disk contents from the original system image as an img file, and use a compression tool (such as gzip) to compress it to generate a system image file, such as k1_clean.img.gz, to obtain a lightweight Ubuntu system.
[0037] Example 3 The present invention will be further described below with reference to specific embodiments, but the present invention should not be limited to the embodiments described. For those skilled in the art, any changes, modifications, substitutions, and integrations to these embodiments without departing from the principles and spirit of the present invention fall within the protection scope of the present invention.
[0038] (a) Basic cutting process A preferred embodiment of the present invention uses the Banana Pi BPI-F3 development board (equipped with a RISC-V K1 SoC) as the target platform. The original system uses the officially released bianbu-24.04-minimal-k1-v2.2 image.
[0039] First, update the software source in the system and install the ROS2 Humble test package to establish a functional verification baseline. This invention uses the core communication functions of ROS2 as the "functional baseline" and "regression test standard" for the trimming process, aiming to ensure that each trimming operation does not compromise the system's support for ROS2 applications. This method, guided by the final application scenario, fundamentally eliminates trimming failures caused by unclear dependencies. Execute the following command: sudo apt update sudo apt install ros-humble-demo-nodes-cpp ros-humble-demo-nodes-py After installation, verify that the ROS2 core communication function is working properly using the following command: source / opt / ros / humble / setup.bash ros2 run demo_nodes_cpp talker ros2 run demo_nodes_py listener If the talker node outputs a Publishing message and the listener node outputs an "I heard" message, it proves that the ROS2 DDS publish / subscribe communication mechanism is working properly. This state can be used as the regression test benchmark for subsequent pruning operations.
[0040] Next, to prevent accidental deletion of necessary dependencies for ROS2 operation during subsequent automated cleanup, a series of core system components are pre-marked as "manually installed." This step is the core difference between this method and blind trimming. Traditional system trimming often only focuses on the accumulation of package sizes, ignoring the complex dependencies and functional couplings between system components, making it easy to accidentally delete critical components. This invention constructs a "protection list" by pre-identifying and locking a specific set of core system components strongly related to ROS2 operation, thus avoiding the risk of accidental deletion from the source. The following command demonstrates how to implement protection: sudo apt-mark manual networkd-dispatcher netplan.io netplan-generatoriproute2 lsb-release systemd-sysv gcc-13-base linux-baselibnl-3-200 libnl-genl-3-200 libnl-route-3-200 libjansson4 zstd; These protected components each perform key functions: networkd-dispatcher handles network status hook scripts; netplan.io and netplan-generator are responsible for network configuration; iproute2 provides low-level network commands; lsb-release maintains system version information; systemd-sysv provides system service compatibility; gcc-13-base is the GCC runtime library; linux-base is the kernel management metapackage; libnl-* series libraries are used for Netlink communication; libjansson4 is used for JSON parsing; and zstd provides compression and decompression functions.
[0041] Then, an automated script is written to systematically uninstall software packages unrelated to ROS2 operation. These removed packages (such as logrotate and rsyslog) are system components analyzed to be irrelevant to core ROS2 communication functions. For example, logrotate is used for log rotation, and rsyslog is a system logging service; in pure ROS2 applications, these can be replaced by lighter-weight mechanisms. Locales and manpages, on the other hand, provide localized support and documentation for users and are unnecessary resources in headless embedded runtimes.
[0042] Crucially, after each round of uninstallation, the script automatically or guides the operator to perform regression tests on the ROS2 demo established during the step of installing and verifying the ROS2 base environment. If the test fails, a rollback is performed via system snapshots or package management logs, or manual intervention is prompted for troubleshooting, thereby ensuring the safety and controllability of the trimming process.
[0043] Then, after trimming at the package level, further delete static files that occupy a lot of space on the disk but are irrelevant to system operation. This step is a deep-level treatment of the "bloat" phenomenon in operating system distributions. Standard Linux distributions contain a large number of static resources such as documentation, fonts, and localization files prepared for general use, which are completely redundant in specific embedded applications (such as ROS2). Direct cleanup at the file level can achieve a size reduction effect that package managers cannot achieve. Execute the following commands to clean up: sudo rm -rf / usr / share / doc / * / usr / share / info / * / usr / share / man / * / usr / share / locale / * / usr / share / fonts / * / var / log / * / var / cache / * Then, for scenarios where extreme space consumption is a priority, further cleanup can be done on subdirectories under ` / usr / share / `, such as groff, bash-completion, vim, and i18n. Additionally, using the command `sudo journalctl --vacuum-time=1s` to clean up system logs, retaining only entries from the most recent second, can significantly free up storage space.
[0044] Finally, the optimized system disk contents are completely exported and compressed using gzip to generate the final deliverable system image file k1_clean.img.gz. The final system image, the complete Linux 6.6 kernel source code, the ROS2 source code package, all trimming and automation scripts, and usage documentation are organized according to a predetermined repository structure and uploaded to a code hosting platform, forming a complete and reproducible project repository. This "image + source code + scripts + documentation" delivery model transforms a one-time trimming result into a foundational platform for sustainable evolution and customization. It significantly lowers the technical barrier to deploying lightweight ROS2 systems on similar RISC-CV edge devices, promoting technology standardization and ecosystem development.
[0045] (ii) Automated trimming toolchain This embodiment focuses on describing a toolchain for modularizing and automating the above-described trimming methods. This toolchain can run as a standalone application or in a continuous integration (CI) environment, and includes the following core modules: Dependency Analysis Module: This module takes as input the current system's package list (dpkg -l) and package dependencies (resolved via apt-rdepends). Optionally, runtime call tracing (such as using strace or trace-cmd) can be integrated to dynamically analyze the system libraries and resources actually called by the ROS2 runtime, thereby generating a more accurate "recommended retention list" and "candidate removal list." The innovation of this module lies in combining static dependency analysis (package relationships) and dynamic behavior analysis (runtime calls), enabling more accurate identification of the system resources truly required by the ROS2 runtime. This avoids the conservative "better to keep the wrong ones than delete the wrong ones" strategy of traditional methods, providing a data foundation for achieving extreme resource optimization.
[0046] The trimming execution module receives a manifest from the dependency analysis module and safely executes commands such as `apt purge` and `apt autoremove --purge` in containers or chroot environments using overlayfs. This module features operation logging and supports rapid rollback in case of operation failures using file system snapshot technology.
[0047] Static file cleanup module: This module scans and deletes redundant static files in the target directory according to predefined cleanup strategies. It generates a detailed deletion list for auditing and space reclamation statistics.
[0048] Regression Testing Module: This is the core module for ensuring the quality of the trimming process. After each critical operation in the trimming execution module, this module is automatically triggered to execute a predefined set of test cases. The test set includes at least: ROS2 demo node communication tests, basic network connectivity tests (such as ping), and status checks of critical system services (such as systemd-networkd). The process will only proceed to the next stage if all tests pass; otherwise, a rollback mechanism or alarm will be triggered.
[0049] Packaging and Metadata Module: After all trimming and testing phases have passed, this module is responsible for calling underlying system commands (such as dd, losetup, gzip) to generate the final system image file. Simultaneously, it automatically collects information such as the build environment, version, and retain / remove lists, generating a structured metadata file.
[0050] The above modules are linked together through a top-level Makefile or CI / CD pipeline (such as GitLab CI / CD) to form a complete automated pipeline from raw image input to automatic trimming, testing, packaging, and finally outputting a deployable image.
[0051] (III) Effect Verification The system image obtained by the above method was tested and verified: Size metrics: The final generated system image file k1_clean.img.gz is approximately 456 MB after compression, achieving extreme size compression compared to the original base image, perfectly meeting the stringent storage requirements of resource-constrained edge devices.
[0052] Functional Indicators: After burning the image to the Banana Pi BPI-F3 development board, the system can start and log in normally. Running the ROS2 Humble talker and listener demo nodes, they can stably and in real-time send and receive messages through the DDS middleware, proving that the core communication framework, underlying network stack, and system scheduling functions of ROS2 are complete and error-free. The successful functional testing verifies the core argument of this invention: through careful dependency management and security trimming, the system size can be greatly reduced without sacrificing its core support capabilities for complex application frameworks (ROS2).
[0053] Reproducibility: The kernel source code, build configuration, trimming scripts, and detailed documentation released with the image ensure that third-party developers can fully reproduce the trimming process and final results in the same environment by following the guidance, demonstrating the high repeatability and scalability of this invention.
[0054] Through the above specific embodiments, this invention clearly demonstrates an Ubuntu system optimization solution that combines deep customization, security and controllability, functional assurance and automation capabilities, effectively solving the system lightweighting challenge faced when deploying ROS2 on the RISC-CV edge computing platform.
[0055] Example 4 A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the lightweight Ubuntu system tailored for the RISCV architecture as described in any of Embodiments 1-3.
[0056] Example 5 A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the lightweight Ubuntu system tailored for the RISCV architecture as described in any of Examples 1-3.
[0057] Example 6 A lightweight Ubuntu system tailored for RISC-CV architecture and supporting ROS2, including: The manual installation status marking module is configured to: obtain the Ubuntu raw system image based on the RISCV architecture, install ROS2 in the Ubuntu raw system image, and mark the core system components required for ROS2 to run as manually installed. The irrelevant package trimming module is configured to trim packages that are irrelevant to ROS2 operation from the Ubuntu raw system image marked as manual installation. The communication function verification module is configured to: deploy the standard test node package and verify the communication function of ROS2; if the communication is normal, execute the static file trimming module; otherwise, return to the step-independent package trimming module. The static file trimming module is configured to trim non-essential static files in the system directory of the original Ubuntu system image. The Ubuntu system generation module is configured to: trim redundant software components and clean up system logs, compress the system disk contents of the trimmed original system image into an image file, and obtain a lightweight Ubuntu system.
Claims
1. A method for tailoring a lightweight Ubuntu system for RISC-CV architecture and supporting ROS2, characterized in that, include: Step 1: Obtain the original Ubuntu system image based on the RISCV architecture, install ROS2 in the original Ubuntu system image, and mark the core system components required for ROS2 to run as manually installed. Step 2: Remove packages that are not relevant to ROS2 operation from the original Ubuntu system image marked as manual installation; Step 3: Deploy the standard test node software package and verify the communication functionality of ROS2; If communication is normal, proceed to step 4; otherwise, return to step 2. Step 4: Trim non-essential static files from the system directory of the original Ubuntu system image; Step 5: Trim redundant software components and clean up system logs. Compress the system disk contents of the trimmed original system image into an image file to obtain a lightweight Ubuntu system.
2. The method for tailoring a lightweight Ubuntu system for RISC-CV architecture and supporting ROS2 as described in claim 1, characterized in that, Mark the core system components required for ROS2 to run as manually installed; including: In the original system image, the core system components required for ROS2 to run include the networkd-dispatcher package responsible for network status management, the network configuration tools netplan.io and netplan-generator, the network command set iproute2, the system information tool lsb-release, the system service compatibility layer systemd-sysv, the compiler runtime library gcc-13-base, the kernel management package linux-base, the network communication libraries libnl-3-200, libnl-genl-3-200, libnl-route-3-200, the JSON parsing library libjansson4, and the compression tool zstd; Use the package management tool apt to execute the installation status command to mark the core system components required for ROS2 to run as manually installed.
3. The method for tailoring a lightweight Ubuntu system for RISC-CV architecture and supporting ROS2 as described in claim 2, characterized in that, Step 2 is as follows: Use the package management tool apt to execute the uninstall command to actively uninstall packages from the original system image that are not related to ROS2 operation, including: Log rotation tool logrotate, system log service rsyslog, console setup console-setup, keyboard configuration keyboard-configuration, keyboard layout data xkb-data, Vim editor common files vim-common, kernel header files linux-headers-*, Z-shell tool zsh, Z-shell common files zsh-common, hexadecimal viewer xxd, file viewer less, dialog box tool whiptail, Wi-Fi connection tool wpasupplicant, disk partitioning tool fdisk, eject device tool eject, localization support locales, internationalization configuration debconf-i18n, MIME type database shared-mime-info, binary toolset binutils, initramfs tool dracut-install, utilities sensible-utils, initramfs tool initramfs-tools-bin, D-Bus user session dbus-user-session, klibc tools klibc-utils*, klibc library libklibc*, man pages.
4. The method for tailoring a lightweight Ubuntu system for RISC-CV architecture and supporting ROS2 as described in claim 3, characterized in that, Deploy the standard test node software package and verify the communication functionality of ROS2; including: Install the standard test node packages for ROS2 Humble in the original system image, including the C++ version of the demo node package ros-humble-demo-nodes-cpp and the Python version of the demo node package ros-humble-demo-nodes-py. In two separate terminal windows, run the talker node and listener node from the standard test node package respectively to verify whether the communication function between the talker and listener nodes is normal, i.e., observe the output of the two terminal windows. If the terminal window running the talker node continuously outputs the published message content, and the terminal window running the listener node synchronously outputs the received message, then the communication is considered to be normal, that is, the publish / subscribe communication mechanism based on DDS in ROS2 is working normally, and the pruning has not damaged the core ROS2 operating environment. If any test node fails to start, exit, or display the expected output, it is considered a communication anomaly.
5. The method for tailoring a lightweight Ubuntu system for RISC-CV architecture and supporting ROS2 as described in claim 4, characterized in that, Step 4 is as follows: Manually delete all contents of static files in the system directory that take up a lot of space but are not related to operation, or keep only some files in the static files as needed; Static files include: document directory, information directory, manual directory, localization file directory, font directory, log directory, and cache directory.
6. The method for tailoring a lightweight Ubuntu system for RISC-CV architecture and supporting ROS2 according to claim 5, characterized in that, In ROS2 embedded applications where extreme optimization is required, all static files are deleted, including those in the system directory such as document formatting tool files, bash auto-completion files, Vim editor files, internationalization files, Thai support files, Deb package checking tool files, Perl modules, public suffix lists, XML data, JavaScript libraries, X Window system files, fault reporting tools, GCC related files, C++ test framework files, aclocal data, error reporting tools, documentation basics, GDB debugger files, graphical visualization tools, initramfs tools, menu definitions, icon files, pkg-config files, policy toolkits, utilities, SGML data, SGML basics, tab settings, Valgrind tools, Aptitude package manager data, DHCP client data, and color management data.
7. The method for tailoring a lightweight Ubuntu system for RISC-CV architecture and supporting ROS2 according to claim 6, characterized in that, Step 5 specifically involves: The automated cleanup command `sudo apt autoremove --purge` automatically identifies and removes orphaned packages, and also completely removes the configuration files corresponding to orphaned packages. Orphaned packages include those that were automatically installed due to dependencies and are no longer depended on by any packages marked as manually installed in the current system state. Execute the system log cleanup command `sudo journalctl --vacuum-time=1s` to clean up the structured log file, deleting all old log entries whose recording time exceeds the set time, and only keeping the latest logs generated within the most recent set time. Use a disk imaging tool to export the trimmed system disk contents from the original system image as an img file, and then use a compression tool to compress it to generate a system image file, resulting in a lightweight Ubuntu system.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the lightweight Ubuntu system tailoring method for RISCV architecture as described in any one of claims 1-7.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the lightweight Ubuntu system tailoring method for RISCV architecture as described in any one of claims 1-7.
10. A lightweight Ubuntu system tailored for RISC-CV architecture and supporting ROS2, characterized in that: include: The manual installation status marking module is configured to: obtain the Ubuntu raw system image based on the RISCV architecture, install ROS2 in the Ubuntu raw system image, and mark the core system components required for ROS2 to run as manually installed. The irrelevant package trimming module is configured to trim packages that are irrelevant to ROS2 operation from the Ubuntu raw system image marked as manual installation. The communication function verification module is configured to: deploy the standard test node package and verify the communication function of ROS2; if the communication is normal, execute the static file trimming module; otherwise, return to the step-independent package trimming module. The static file trimming module is configured to trim non-essential static files in the system directory of the original Ubuntu system image. The Ubuntu system generation module is configured to: trim redundant software components and clean up system logs, compress the system disk contents of the trimmed original system image into an image file, and obtain a lightweight Ubuntu system.