Week 01 - Project management

This week is the first week of Fab Academy, and the main topic is Project Management. In fact, project management is not as complicated as it sounds. At its core, it is about planning, organizing, and supervising a project from the beginning to completion, helping us move forward with our work more efficiently.

In the theoretical part of the course, we learned several practical project management methods. For instance, the 80/20 principle — and in reality, the situation is even more extreme, resembling the 95/5 principle — which means that 80% of the tasks only take 20% of the time, while the remaining 20% of critical tasks will occupy 80% of the time. We also discussed how to balance demand-side and supply-side time, how to classify task priorities, and how to run multiple tasks in parallel to avoid wasting time or getting stuck in inefficient workflows. These ideas may seem simple, but they can help us manage our time better and clarify priorities during the following weeks of the course.

There are two core learning tasks this week, which also form the foundation for the rest of the program. The first one is distributed version control, mainly using Git. The second one is web development. In simple terms, we need to learn how to use Git to manage code versions, which helps prevent problems such as accidental deletion or losing track of changes during development. This will provide a solid foundation for our future project work. At the same time, we also need to build our personal website, which will introduce ourselves and showcase all the work and assignments we complete throughout the course.

In addition to these two main tasks, there are two other important things to complete this week. First, we need to read and sign the Fab Academy Student Agreement and commit it to our repository. Second, we need to start thinking about and writing a description of our final project, defining the direction of what we would like to achieve by the end of the course.

Weekly Task List：

• Read and sign the student/instructor/lab agreements, and commit them to your repositories.
• Work through Git tutorials, learn the basic operations, and be able to manage code versions independently.
• Build a personal site in the class archive describing you and your final project.

1. What Problems Did I Need to Solve This Week?

1.1 Confusion and Uncertainty When First Receiving the Assignment

When I first received the assignment for Week 1, I felt quite confused. Tasks such as “Git operations,” “HTML modification,” and “project sketch” were listed, but I had no clear idea where to start.

During this week, I followed the assignment requirements step by step and began exploring each task. Along the way, I encountered many questions and uncertainties, but gradually found solutions to them. Every time I solved a problem, I felt a strong sense of accomplishment.

The following sections document my complete learning process for this week, including my thoughts, questions, and practical steps. It records the journey from unfamiliarity to gradually becoming more comfortable with the tools and workflow.

1.2 Re-understanding the Goal of the Assignment

The goal of this week's assignment was not simply to complete a single technical task. Instead, the real objective was to publish a project as an actual website that others can access online.

To achieve this goal, the first problem I needed to solve was how to manage and continuously update project files in an organized way. Therefore, the first step was learning how to use Git to manage version control for the project, and using GitLab as a remote repository to synchronize and store all files. This step ensured that even if the project files were modified many times, the changes would remain organized and traceable.

After the repository could be synchronized successfully, the next question became: how can these files be presented as a web page that people can access? To understand this, I needed to learn which files in the repository were actually used to generate the website. I began modifying the HTML files inside the public directory, and used the commit and push process to verify whether my local changes were correctly reflected on the online page. Through this process, I gradually built a clear understanding of the workflow: local modification → commit → deployment result.

Once the webpage could update correctly, another issue appeared when working with media files. Uploading original images and videos directly often resulted in files that were too large, which could slow down page loading and make repository commits inefficient. Because of this, I needed to learn how to compress images and videos before uploading them.

By using specialized compression tools, I was able to reduce the file sizes to within the required limits, upload them again, and reference them in the webpage. This helped resolve the balance between page presentation and performance.

As the content gradually increased, manually writing HTML became difficult to maintain. Therefore, I started introducing a website template to unify the structure of the pages. This step required understanding the template’s directory structure, configuration files, and content generation rules. After learning how the template system worked, I migrated my existing content into the new structure, ensuring that the website could still be generated correctly while also becoming easier to maintain and update in the future.

Throughout this entire process, each technology I learned was not isolated. Instead, every new step was introduced to solve a problem that appeared in the previous step. In the end, what I completed was not just a webpage, but a complete technical workflow—from project management to content publishing.

2. Git and GitLab Operation Records

2.1 What problems does Git solve?

Before starting to learn Git, I first pondered a question: Why do we need to learn Git, and what problems does it help us solve?

It is imaginable that during project development, we will constantly modify and adjust our own files. At the same time, we also hope to save the old version while updating to the latest version, because we are not sure if we will need it again. It would be even better if we could record the history of each modification and allow us to revert to a previous version at any time.

Git, on the other hand, meets these requirements well. It is a distributed version control system that can record the history of every modification in a project and allows us to revert to previous versions at any time.

The so - called distributed system means that each developer's computer has a complete copy of the repository, rather than relying solely on a central server. Even in an offline state, version recording and management can still be carried out, and synchronization with the remote repository can be done after connecting to the network. In contrast to the distributed system is the centralized system, where all code is stored on a central server, and version recording and management require network connectivity. If the server or network encounters problems, development work will also be affected.

Using Git can bring us several obvious benefits:

• Every modification is recorded
• can return to the previous version at any time
• Project files will not become chaotic due to multiple modifications
• Local files can be synchronized and backed up with remote repositories

During this Fab Academy learning process, all my assignments and learning records will also be managed through a Git repository and ultimately published on my personal website. So, let's start by learning Git.

2.2 Getting Started with Git

2.2.1 Install Git and Configure SSH Key

Based on the already completed Git installation, before formally using Git, I need to first complete the SSH configuration. This step is mainly to enable GitLab to recognize the identity of the current computer, so that password-free connection can be achieved for each subsequent code submission or synchronization.

Step 1: Generate SSH Key

Open the command-line terminal and enterssh-keygen -t ed25519 -C "your_email@example.com"to generate an SSH key. Note: your_email@example.comneeds to be replaced with the email address you used when registering for GitLab.

Step 2: View and copy the public key

After running the above command, the terminal will output information related to the successful generation of the key. The generated SSH key is generally saved in the C:\Users\PC\.ssh\directory of the current user. You need to view and copy the public key.

Step 3: Add the public key on GitLab

First, log in to GitLab, go to 「Edit profile」→「SSH Keys」, and add the public key.

Step 4: Verify if the connection is successful

In the local command line terminal, enter the command ssh -T `` git@gitlab.com to verify if the connection is successful.

2.2.2 Add Remote Repository

Suppose only a Git repository has been created locally, which means I can perform version control locally. However, once my local computer is damaged or files are accidentally deleted, version records will encounter issues, and it will also be impossible to synchronize progress across multiple devices.

Therefore, we can associate and push the local repository to the GitLab remote repository, and these issues will be readily resolved.

The specific implementation steps are as follows:

Step 1: Create a remote repository on GitLab

First, find the "New project/repository" button in the upper right corner of GitHub and create a new repository.

Next, set up information such as the warehouse name and visibility,

Step 2: Initialize a Git repository locally

In this step, I will initialize the local Git repository and perform the first commit using 4 command lines:

1. Open the project root folder, right-click to open Git Bash, and enter the commandgit initto initialize the Git repository. This step will generate a.githidden folder in the project root directory, which will be responsible for storing the core data of subsequent version management;
2. Enter the commandgit status, which allows you to see which files have not been tracked by Git;
3. Enter the commandgit add.to add files to the staging area;
4. Finally, enter the commandgit commit -m "Initialize local repository"to submit the first version. After completion, the local files will be under Git's version control.

Step 3: Associate the remote repository

1. Copy the SSH address of the remote repository provided by GitLab.

1. Return to the Git Bash terminal in the root directory of the local project and enter the following commandgit remote add origin <repository address>. Taking my current operation as an example, the command is:git remote add origin ``git@gitlab.fabcloud.org``:xin-ruili/learn.git
2. Continue to enter the commandgit remote -v to check if the association was successful:

Step 4: Push the contents of the local repository to the remote repository

Enter the following command to push local commits to GitLab:

C

git push -u origin main
//如果你的默认分支不是 main，用 master 或对应分支名。
//-u 参数表示把本地分支和远程分支关联，以后推送可以只用 git push。

Then open the GitLab repository page, and after refreshing, you will see that the content of the local files has already appeared in the remote repository.

2.2.3 Clone from Remote Repository to Local

Step 1: Copy the SSH address of the GitLab repository

C

git@gitlab.fabcloud.org:academany/fabacademy/2026/labs/chaihuo/students/xin-ruili.git

Step 2: Open Git Bash and use the command git clone to clone the repository

Step 3: Enter yes

When pushing or cloning a remote repository for the first time via SSH, the system prompts "Do you trust the remote server?" Enter yes in the command line and press Enter to continue. Subsequent operations do not require entering yes.

Step 4: Check the local folder for verification

2.2.3 File Modification and Push

After establishing a connection between my local repository and the remote repository, when updating my personal website and submitting assignments in the future, I will perform operations locally, and then synchronize the changes to the GitLab remote repository after the operations are completed.

After completing the modification and saving of the local file, I also want to synchronize the local changes to the remote repository. The operation steps are as follows:

Step 1: Commit changes to the local repository

Execute the following command in the Git Bash terminal to record the changes to the local repository:

C

git add .
git commit -m "描述本次修改内容"

git add. adds all modified files to the staging area.

git commit -m "description" will record these changes as a version snapshot, making it easy to roll back or view history at any time.

Step 2: Push changes to the remote repository

Continue to execute the following command to synchronize local commits to the GitLab repository:

C++

git push

After completion, you can refresh my GitLab repository, and then you will see the latest content we pushed.

To summarize, the operation processes for file modification and push are respectivelymodify -> stage -> commit -> push. Modify means editing content locally, staging (add) tells Git which changes need to be recorded, committing (commit) saves a historical snapshot of the changes, and pushing (push) synchronizes the local version to the remote repository.

3. Build a Personal Website

After completing the Git configuration, I then began to build my personal website. I prefer to use a static site generator to build the website framework rather than writing HTML and CSS from scratch, and I chose to do this through a static site generator like MkDocs.

Using MkDocs, I only need to focus on writing content in Markdown (.md) syntax, and the page structure, navigation bar, etc. of the website can all be automatically generated, which saves me a great deal of time and also provides many ready-made features and styles.

3.1 Install MkDocs

3.1.1 Install the Python Environment

Before starting to use MkDocs, we need to prepare a Python (version ≥ 3.8) environment. This is because MkDocs itself is written in Python, and subsequent installation and operation both rely on Python.

After downloading and installing Python (version ≥ 3.8), you can enter python --version or python3 --version in the command line for verification.

3.1.2 Install MkDocs

After confirming that Python can be used normally, open the command line (terminal) and enter the following command to install the required tools:

HTML

pip install mkdocs -U
pip install mkdocs-material -U

Note that it can be directly copied together into the command line, which is very convenient, where:

mkdocs represents the core of the main documentation library

mkdocs-materialrepresents a nice code theme

The running results are as follows:

At this point, the installation is complete.

3.2 MkDocs Initialization and Local Debugging

3.2.1 Create a New MkDocs Project

We first create the main folder, and then enter the following code in its directory:

C

mkdocs new ./

We will see that there is one moremkdocs.ymlfile anddocsfolder in the directory, indicating successful creation

Project Structure Analysis:

• docs/: Stores documents (the homepage is index.md)
• mkdocs.yml: Core configuration file

3.2.2 Real-time preview and generate a static website

After completing the basic configuration of the MkDocs project, enter the following command:

C

mkdocs build --clean
mkdocs serve

Use mkdocs serve, this command will start a temporary server locally, open http://127.0.0.1 ``: 8000/ in the browser, and you can see the page effect of the current website . The feature of this command is real-time update, which means that when I modify and save the project file again, the web page will also automatically update.

Usemkdocs build, this command will generate asite folder in the project directory, which contains the complete static website files, i.e., the files for subsequent web deployment. As long as you upload this folder to a platform or server that supports static web hosting, you can access it in a browser. In this Fab Academy learning process, we will submit this folder to the GitLab repository for deployment and complete the website publication through GitLab Pages.

Visit the URLhttp://127.0.0.1:8000/, and we will see:

This is our home page at this moment. Next, we can modify it, which is by default done in docs folder's index.md.

3.3 Configuremkdocs.ymlfile

In MkDocs projects, there is a very important configuration file called mkdocs.yml. This file is mainly used to control the basic settings of the entire website, such as the website name, theme style, navigation structure, etc.

Next, open themkdocs.ymlfile using VScode software:

We will find that there is nothing inside, and we can configure it.

3.3.1 Change Site Name

The name of our site can be set via the site_name parameter, and this name will be displayed in the top left corner of the web page.

3.3.2 Modify mkdocs Theme

Copy the following content into VScode:

C

theme:
  name: material

The meaning is that we changed the theme to material, which is a very nice theme we installed previously.

The theme determines the overall interface style, layout method, and navigation style of the website. MkDocs supports many different themes (Theme).

As a result, you will find that our web page display has changed to this, with a different style compared to before.

3.3.3 Navigation Bar (Navigation) Settings

Throughnavsettings, note that the address here is based on the docs folder, and the file name and file address we create in the folder must be consistent with those set in nav.

Copy the following code tomkdocs.ymlfile

Bash

# 基础导航配置
nav:
  - 首页: index.md
  - 计算器功能:          # 分组名称
      - 加法函数: 计算器功能/add.md  # 分组下的子导航
      - 减法函数: 计算器功能/sub.md  # 子导航对应docs/add.md、docs/sub.md
  - 关于: about.md        # 单独的导航项
  - 更多: https://freakstudio.cn/  # 外部链接

The page can be seen as follows:

Click "More" and you will be redirected to our designated external link:https://freakstudio.cn/

We can also place the navigation bar at the top, which requires us to manually enable it. Copy the following code into mkdocs.yml file:

C

features:
- navigation.tabs  # 页面上方的标签页
- navigation.tabs.sticky  # 让顶部导航滚动时固定

We can now see the navigation bar appearing in the upper position.

3.4 Deploy the MkDocs website to GitLab Pages

We have now completed the editing of the website content and the local build of MkDocs. The next step is to deploy the generated static web pages to GitLab Pages so that others can access them via a browser. Additionally, we will continue to make ongoing modifications to the documentation and content locally, and these changes also need to be synchronized to the online website.

Break down the goal into two key points: First, publish the previously generated site/ folder to GitLab Pages so that the web page can be accessed; Second, after each modification and adjustment to the local files, synchronize the updates to the remote repository via Git so that the website will also be automatically updated.

During this process, the tools I used and their corresponding functions are as follows:

• Git: Responsible for version control and synchronization between local and remote repositories; Skill points: Clone repository, add → commit → push
• MkDocs: Generate static web pages from Markdown documents; Skill point: The build command generates the site/ folder
• GitLab Pages: Host static web pages and provide access URLs; Skill point: Publish the generated website files to GitLab Pages for display.
• GitLab CI/CD: Enables automated build and deployment, improving modification efficiency. Skill point: Automatically executes the build and release process through .gitlab-ci.yml configuration.

3.4.1 Manual Deployment Process

Step 1: Prepare local files

Generated the site/ folder, and checked whether HTML, image, and video files are within the specified size limits.

Step 2: Synchronize the remote repository

Clone the entire GitLab repository, copy the contents of site/ to the public/ folder in the repository, overwriting the existing contents.

Step 3: Submit and push changes

C

git add public
git commit -m "更新网站内容"
git push origin main

Step 4: Verify whether the web page is effective

Open the GitLab Pages URL to check if the page is displayed. If the page does not display, you can check if the files within the public directory are complete.

3.4.2 Automatic Deployment (CI/CD) Process

We have already achieved the deployment of the web page through manual operation, but I found that in this way, every time we modify a document, we have to regenerate the web page and upload the files to the repository, which is a rather cumbersome process. If we need to update the website frequently and in large quantities in the later stage, it will be very laborious. So, is it possible for me to simply modify the document and have the web page automatically updated?

The automatic deployment (CI/CD) provided by GitLab can solve the above problems. It can implement an automated process, allowing each local modification push to the repository to automatically complete website building and publishing, eliminating the need for cumbersome manual operation steps.

Let's take a look at the automatic deployment process of GitLab Pages:

1. Locally modify the Markdown document and submit it to the GitLab repository
2. GitLab detected a new push operation
3. CI/CD reads the .gitlab-ci.yml configuration file in the repository
4. GitLab Runner executes build commands (such as mkdocs build) according to the configuration
5. Generate static web page files (HTML, CSS, JS)
6. Publish the generated web page to GitLab Pages
7. Users access the updated website via a browser

3.4.2.1 Clean up the warehouse

Since I previously performed a manual deployment, there is a public folder in the repository, and the upcoming automated deployment will automatically generate this folder. To avoid conflicts, we will directly delete the old public folder.

Meanwhile, add a .gitignore file to the local root directory and add the following content:

C

# 忽略MkDocs构建产物，永不提交
site/
public/
# 忽略Python缓存文件（可选，不影响核心）
__pycache__/
*.pyc

This step is also mainly to avoid file conflicts that could lead to pipeline failure. After writing is completed, enter the following command to synchronize to the remote repository:

C

# 1. 把删除public和新增.gitignore都加入暂存
git add .

# 2. 提交修改
git commit -m "删除旧public文件夹+添加.gitignore，避免构建产物干扰CI/CD"

# 3. 推送到GitLab仓库，触发新流水线
git push origin main

3.4.2.2 Write a simplest .gitlab-ci.yml configuration file

To make CI/CD effective, I need to add a key file in the root directory of the repository:.gitlab-ci.yml. It will tell CI/CD what environment to use, which operations to execute, and which files to generate for release.

After some thought, I tried to write a minimized version:

YAML

# 1. 指定了 CI/CD 运行环境，用的是 Python 3.12 的官方镜像（有Python才能装MkDocs）
image: python:3.12

# 2. 定义流水线阶段：先构建（build），再部署（deploy）
stages:
  - build
  - deploy

# 3. 基础MkDocs + material主题 + 你用到的所有插件（按本地列表加）
before_script:
  - pip install mkdocs mkdocs-material   # 插件按需加，用空格分隔

# 4. 第一个任务：构建静态网站（对应build阶段）
build_site:
  stage: build
  script:
    - mkdocs build --clean  # 生成静态文件，--clean表示清空旧的site文件夹，避免冗余
  artifacts:
    paths:
      - site
  only:
    - main  # 或者你的默认分支名称，比如 master

# 5. 第二个任务：部署到GitLab Pages（对应deploy阶段）
pages:
  stage: deploy
  script:
    - mv site public # 把build阶段生成的site文件夹改名成public（GitLab Pages只认public文件夹）
  artifacts:
    paths:
      - public   # 上传public文件夹，GitLab会用它部署网站
  only:
    - main  # 只有推main分支时才执行部署

That is to say, after I modify the document and push, GitLab will automatically perform the build and deployment.

3.4.2.3 Submission and Triggering of CI/CD

After completing the writing of the .gitlab-ci.yml configuration file, we upload the changes to GitLab to make the automatic deployment actually run.

Step 1: Remember the page before modification

To clearly see the modification effects after automatic deployment, we first record the current state of the online website as a reference, and we save this screenshot for direct comparison of visual changes after modification later:

Step 2: Complete content modification locally

Now we are making modifications in the local index.md file, changing the background color to orange-yellow:

You can perform command-line input locally mkdocs serve to preview first and confirm that everything is correct:

Step 3: Commit local changes to Git

Right-click on the blank area of the local repository root folder, select Git Bash, and enter the following command:

C

git add .
git commit -m "更新文档，触发 CI/CD"
git push origin main

Step 4: Check the running status of the CI/CD pipeline

After the push is successful, GitLab will automatically detect this push operation and start executing a pipeline (automated pipeline) . This step does not require manual operation on our part.

Go to the GitLab repository page, click on CI/CD → Pipelines in the left menu to view the current pipeline's running status.

You will see a new pipeline record, and its initial state is usually running, indicating that GitLab is automatically executing the steps in .gitlab-ci.yml.

When the pipeline is in the running state, you need to wait patiently and do not repeatedly perform the push operation. When the pipeline state changes to passed , it indicates that the entire process has been successfully completed.

Step 5: Verify the web page update and visit the URL assigned by GitLab Pages

In the 「Project information」 area on the right side of the current GitLab repository page, find and click GitLab Pages, and the browser will automatically open and jump to your personal website page.

As can be seen, the page has been successfully updated, displaying the latest effect after we modified the background color:

3.4 Pitfall Record

It should be noted that during the process of configuring GitLab Pages and CI/CD, I didn't complete it in one go. I encountered some pitfalls along the way, which can be considered an experience of learning while doing. I'd like to share the problems I encountered and their solutions, hoping they will be of reference value to fellow students who will also work on MkDocs + GitLab Pages in the future.

3.4.1 Pipeline failure caused by incorrect build path

When I first configured .gitlab-ci.yml, I directly copied an example from the internet, but the Pipeline failed as soon as it started.

After a problem occurs, on the left side of the repository page, Build → Pipelines can be used to find the corresponding pipeline record, Build → Jobs can be clicked to open the log and view the complete error information.

C

ERROR: Job failed: exit code 1
Uploading artifacts...
WARNING: site/: no matching files.

From the logs, it can be seen that GitLab did not find the site folder, so it was unable to generate Pages.

After carefully checking the .gitlab-ci.yml configuration, I found that the problem lies in the path configuration of artifacts.paths. The static web page directory generated by MkDocs by default is site. If the path is written incorrectly or the directory is not located in the root directory of the repository, CI/CD will not be able to find the files to be published.

C

  artifacts:
    paths:
      - site

The solution is to make the configuration in .gitlab-ci.yml consistent with the actual generated path. We can choose to change the location of site/ to ensure it is in the root directory without modifying the code.

3.4.2 Dependencies are missing in the CI environment

After resolving the path issue, I thought everything was ready, but when I ran the Pipeline next time, a new error occurred:

C

$ mkdocs build --clean 
Aborted with a configuration error! 
ERROR - Config value 'theme': Unrecognised theme name: 'material'. 
The available installed themes are: mkdocs, readthedocs 
Cleaning up project directory and file based variables 00:01 
ERROR: Job failed: exit code 1

The error log shows that the theme material cannot be found, but previously we were able to preview it normally locally.

It turns out that the environment in which CI/CD runs is brand new, so all themes, plugins, or dependencies used by local MkDocs must be reinstalled in the .gitlab-ci.yml file's before_script. Therefore, I can simply install all the dependencies I use through the .gitlab-ci.yml file's before_script.

4. Conception of the Final Project

In this Fab Academy course, I plan to attempt to build an open-source embedded device ecosystem oriented toward maker and educational scenarios. The entire project will be centered around a standalone terminal device, and around this device I will gradually build hardware modules, a driver system, and a software distribution platform.

The core terminal device of the project is tentatively named GraftTouch-Deploy. It can be understood as a “micro intelligent terminal” designed for makers, with a form and usage similar to a small development device or a maker-oriented handheld device. The device will integrate a main controller, display, network communication capability, and several basic peripherals, while also reserving standardized interfaces for expanding various sensor modules.

4.1 Hardware

In terms of hardware, the terminal is planned to use ESP32-S3 or Pico2W as the main controller platform, and will integrate a 3.2-inch display for human–computer interaction and visual display. At the same time, the device will also include a 4G communication module, enabling it to connect to the network independently. This allows the device to perform functions such as remote updates, data uploading, and application downloads.

To provide richer functionality, the terminal will also integrate several built-in components, such as a gyroscope, buzzer, speaker, SD card interface, and WS2812 LED array.

To expand the device capabilities, the terminal board will provide Grove standard interfaces. Through these interfaces, various sensors or actuator modules can be connected, such as environmental sensors, input devices, and control modules. In the future, I plan to design and manufacture a series of self-developed modules following the Grove interface specification, so that different modules can maintain good compatibility.

4.2 Software Layer

On the software side, this project will be developed based on uPyOS, which is a modified version of a MicroPython-based system. The core goal of the system is to implement functional modules as much as possible using pure .mpy (MicroPython bytecode) drivers.

The advantage of this approach is that it reduces dependence on the underlying firmware, allowing driver code to be migrated across different development boards and improving system compatibility.

Within the uPyOS framework, sensors and peripherals will be managed through modular drivers. The system will make use of existing components such as the Sensor Manager, Audio Manager, Storage Manager, UI Manager, and Task Manager to encapsulate driver logic in a unified way.

At the same time, the system will follow the Activity lifecycle mechanism defined in uPyOS and use tools such as asyncio to implement asynchronous tasks. For example, the system can read gyroscope data in real time and synchronize it to the display, or control WS2812 lighting effects according to the terminal status.

In addition to hardware and drivers, this project also attempts to build a simple software distribution ecosystem. All module drivers can be uploaded to the uPyPi repository, and can be remotely installed and version-managed through the MicroPython mip tool. In this way, when users need a specific sensor driver, they can directly download and install it online without manually copying code.

Furthermore, I hope to implement a simple application store mechanism on uPyOS. Drivers or functional modules can be packaged as installable applications, such as a gyroscope monitoring application, lighting control application, SD card file management, and audio playback. Users can download and install these applications directly through the terminal device and manage them through the system interface. With the help of the device’s 4G network capability, OTA updates and remote distribution may also be realized in the future.

Overall, the goal of this project is to attempt to build a complete open-source embedded development ecosystem: forming a relatively complete chain from hardware terminal → sensor modules → MicroPython drivers → software package distribution → application system.

Through this approach, the project aims to reduce the barrier to embedded development and allow more makers and students to quickly develop and combine hardware applications using Python.

During the Fab Academy learning process, I will gradually complete the structural design of the terminal device, the development of some hardware modules, the implementation of system functions, and the construction of the basic software ecosystem.

5. Reference Links

Useful Git Learning Link 1:https://liaoxuefeng.com/books/git/introduction/index.html

Useful Git Learning Link 2:https://www.runoob.com/git/git-tutorial.html

MkDocs Chinese Version Tutorial: https://wcowin.work/Mkdocs-Wcowin/blog/websitebeauty/mkdocs-translate/

mkdocs Documentation Generation, Quick Start Guide to Python Self-Documentationhttps://www.cnblogs.com/BEMAKE/p/mkdocsTutorials.html

MkDocs Themes：https://github.com/mkdocs/mkdocs/wiki/MkDocs-Themes

HTML5 UP Web Templates:https://html5up.net/

Beautiful template webpage resource link 1:https://sc.chinaz.com/tag_moban/JingTai.html

Nice template web page resource link 2:https://startbootstrap.com/themes

Nice template web resource link 3:https://freebiesbug.com/

Free SVG Background Generator:https://bgjar.com/

Free SVG Icon Library:https://heroicons.com/

Scroll Animation Library AOS:https://michalsnik.github.io/aos/

AI Assistance：

During the preparation of this documentation, ChatGPT (GPT-4) was used as a language assistance tool.

It helped with sentence polishing and translation from Chinese to English to improve readability and clarity.