Week 19 - Invention, Intellectual Property & Income

The theme of this week is Invention, Intellectual Property, and Income . The task requirements given on the course page are: Course Page: https://fabacademy.org/2026/classes/invention_IP_business/index.html

This week's assignment requires us to develop a communication plan for the final project and continuously track progress during the final project's closing phase:

• Which tasks have been completed, and which tasks remain?
• Which parts have already been worked on, and which haven't?
• Which issues still need to be addressed?
• What's next and when?
• What have I learned from this project?

For my final project Maker Assistant , Week 19 is the stage of transitioning from "building the device" to "how this project will be shared, protected, maintained, and further developed after completion".

1. Understanding this week's tasks

After several weeks of enclosure design, PCB organization, ESP32 firmware development, BLE communication implementation, voice prompt integration, and system integration, my final project has evolved from a concept into a working prototype.

However, the final project of Fab Academy should not merely be a small device that can light up and play voice messages. It also needs to address more long-term questions:

• How will this project be made public in the future?
• Which files can be reproduced by others?
• How do I want others to use, modify, and distribute it?
• Which parts need to be open source, and which parts need to retain attribution or restrict commercial use?
• If it continues to develop, how might it generate revenue or have an impact?

Therefore, this week I will organize Maker Assistant from four aspects: intellectual property, communication plan, revenue model, and project progress.

2. Project Review

Maike Assistant is a desktop status feedback device designed for AI programming workflows. It can convert the status of Claude Code, Codex CLI, or similar AI Agent tools in the terminal into lights, voice, and screen animations.

The problem it solves is that users do not need to constantly stare at the terminal while using AI Agent for programming, and can still know whether the current task is running, waiting for approval, has completed, or has encountered an error.

The system link is as follows:

C++

AI Agent 状态
      -> 电脑端 Hook / Daemon 捕获
      -> BLE 状态协议发送
      -> ESP32 设备接收
      -> 灯光 / 语音 / 屏幕反馈

The most mature version currently is Clock Alarm Edition . It uses ESP32-C3, WS2812B, MAX98357A I2S power amplifier, small speaker, and 3D printed enclosure to complete basic status alerts. The Panel / D-Shell version serves as a subsequent expansion direction, used to display screen animations and multi-session information.

3. Intellectual Property Strategy

The Maker Assistant includes software, hardware, circuits, housing, and a character-based appearance, so a single license cannot cover all content. I adopt a tiered licensing approach.

3.1 Software and Firmware: MIT License

ESP32 device firmware, computer Python daemon, hook bridge, state protocol parsing, BLE transmission logic, and test scripts are licensed under MIT License.

The reason for choosing the MIT License is:

• It is simple and permissive, facilitating others' learning and secondary development;
• The code section heavily relies on the open-source ecosystem, such as MicroPython, aioble, bleak, esptool, mpremote, etc.;
• I hope others can apply the state protocol and feedback logic to their own devices;
• The software component of the project is more suitable as an open tool rather than a closed product.

This means that others can use, modify, distribute, and even commercially use these codes, but they must retain the original copyright and license statements.

3.2 3D Shell and Character Appearance: CC BY-SA 4.0

3D printed shells, character accessories, display images, and visual design are released under the concept of CC BY-SA 4.0.

The reason for choosing this license is:

• allows others to learn, print, modify, and remix;
• It is required to retain the signature to prevent the design source from being completely erased;
• Requires sharing in the same way, allowing the improved version to continue to return to the community;
• is more in line with the spirit of Fab Academy and maker education than being completely closed.

Regarding the character-based appearance, I hope others can modify it to create desktop companions with different styles, rather than simply replicating my version.

3.3 PCB and Hardware Materials: Open Source Hardware Direction

PCB schematics, Gerber files, BOM, and assembly instructions are planned to be released in the form of open-source hardware. For personal learning, teaching, and small-scale reproduction, I hope they will be open.

If mass production is entered into subsequently, further organization will be required:

• Clear version number;
• Traceable BOM;
• Test fixtures and quality inspection processes;
• Safety and electromagnetic compatibility related inspections;
• Trademark and Brand Usage Guidelines.

3.4 Name and Brand

As the project name, I hope to retain a clear signature for "Maker Assistant". The code and hardware can be open source, but the project name, demonstration page, and character image need to be prevented from being directly used by others for misleading commercial sales.

If the project continues to be productized in the future, we can consider registering a trademark or at least formulating brand usage instructions.

4. Communication Plan

The dissemination goal of this project is not just to throw the files into a repository, but to enable others to understand, reproduce, and modify this project.

4.1 Fab Academy Project Page

The Fab Academy page is the most official location for project documentation. Here, the final project documentation, presentation diagrams, presentation videos, BOM, production process, and downloadable files will be stored.

Its function is:

• As course review materials;
• Record the complete production process;
• Indicate which parts were designed and manufactured by me;
• Retain long-term accessible project archives.

4.2 GitHub Open Source Repository

I will organize the final code into a public GitHub repository:

https://github.com/FreakStudioCN/MicroPython_Claude_Assistant_Public

The warehouse needs to contain:

• README.md Project Introduction;
• Device-side MicroPython firmware;
• Computer-side daemon and hook bridge;
• Installation and Flashing Instructions;
• BLE pairing and testing methods;
• Status Protocol Description;
• Voice resource generation script;
• Test script;
• License file.

GitHub's advantage is that it is more suitable for other developers to fork, submit issues, and pull requests.

4.3 Downloadable Manufacturing Files

To enable others to truly reproduce the project, I will organize the following manufacturing documents:

• 3D enclosure STL / STEP files;
• 2D sticker, display image, and icon files;
• PCB Gerber files;
• Bill of Materials (BOM);
• Firmware file;
• Programming tool or programming instructions;
• Assembly step diagram;
• Test list.

Just releasing the code is not enough. For a Fab Academy final project, the hardware, enclosure, electronics, and assembly files must correspond to each other.

4.4 Video and Demonstration Dissemination

The Maker Assistant is a status feedback device, and it is difficult to illustrate its value solely through text. Therefore, a video demonstration is needed.

Video content plan includes:

• Claude Code or Codex runs tasks;
• The device switches from idle to working;
• Light and voice reminders while waiting for approval;
• Green light and completion voice when the task is completed;
• Red light and error prompt when an error occurs;
• Comparison of Clock version and Panel / D-Shell expansion direction.

Videos can be posted on the Fab Academy page, Bilibili, YouTube, or in the project README.

4.5 Maker Community and Workshop

This project is suitable for display in maker spaces or AI tool sharing events. It transforms abstract software states into a visible and audible desktop device, making it highly suitable as a workshop project.

Subsequently, a simplified workshop version can be designed:

• Prepare PCB and 3D printed enclosure in advance;
• Participants weld a small number of components;
• Burn firmware;
• Pair with a computer;
• Trigger the simulation state;
• Modify the light color or voice prompt.

This can enable more people to understand the relationship between embedded systems, communication, AI tools, and physical interaction.

5. Revenue and Sustainability Model

My primary goals are education and open-source dissemination, but if the project is to be maintained in the long term, sustainable methods need to be considered.

5.1 DIY Kit

The most direct way to generate revenue is to produce the Maker Assistant DIY Kit .

The kit may include:

• Printed Circuit Boards (PCBs) that have been proofed or soldered;
• ESP32-C3；
• WS2812B；
• MAX98357A；
• Speaker;
• Screws and hot-melt copper nuts;
• 3D printed enclosure or print file;
• Flashed basic firmware;
• Assembly Instructions.

This can reduce the difficulty of procurement when others reproduce the project. For makers, the most troublesome part is often not the code, but purchasing scattered components from different platforms.

5.2 Education Workshop

Maker Assistant is also suitable for creating an AI + hardware interactive workshop.

Workshops may include:

• Introduction to AI Agent Workflow;
• ESP32 and BLE Basics;
• WS2812B Lighting Control;
• I2S voice playback;
• 3D printed enclosure assembly;
• Claude Code Hook or simulated state access;
• Finally, each person took away a small device.

This approach does not merely sell hardware, but rather a complete learning experience.

5.3 Customize Desktop Status Devices

In addition to AI programming tools, many scenarios also require physical state reminders, for example:

• CI/CD Build Status;
• Server task monitoring;
• Status of experimental equipment;
• Multi-station production status;
• Remote task completion reminder.

If the project continues to develop, desktop reminder devices with different appearance and status protocols can be customized for teams or laboratories.

5.4 Software Services and Installation Support

For non-technical users, installing hooks, configuring BLE, and flashing firmware may still be complex. Therefore, the following can be provided:

• Graphical installation tool;
• Device Pairing Tool;
• Firmware Upgrade Tool;
• Remote configuration support;
• Team Edition Status Board.

This part can become a service revenue that is more sustainable than the hardware itself.

6. Final Project Progress Tracking

6.1 Completed tasks

The parts that have been completed so far include:

• Determine the project direction: AI Agent desktop status feedback device;
• Specify the main hardware version: Clock Alarm Edition;
• Design state classification: idle, working, pending, completed, error, disconnected;
• Design state protocol;
• Write the computer-side hook bridge and daemon;
• Write ESP32 device-side firmware;
• Implement BLE status transmission;
• Implement WS2812B lighting feedback;
• Implement voice broadcast for MAX98357A and speaker;
• Design 3D printed shells and character accessories;
• Completed partial PCB design and soldering tests;
• Complete basic assembly;
• Organize the final project documents, presentation diagrams, and presentation videos;
• Write installation, programming, and testing scripts;
• Completed basic real-world scenario testing.

6.2 Remaining tasks

The remaining tasks are mainly focused on stability, documentation, and reproducibility:

• Continue to optimize the BLE disconnection and reconnection logic;
• Check if the README in the final repository is clear enough;
• Organize the final downloadable files;
• Supplement assembly drawings and wiring connection diagrams;
• Check if the BOM table is consistent with the actual version;
• Add license statements to 3D files, PCB files, and code;
• Organize the final presentation video and presentation images;
• Conduct a complete reproduction test from programming to pairing;
• Delete temporary debugging files and irrelevant content;
• Prepare the final defense instructions.

7. Which parts are already working?

The currently well-performing parts are as follows:

7.1 The status link can be successfully established

Claude Code events can enter the computer daemon via the hook bridge, then be converted into status messages and sent to the ESP32. The device can switch lights and voice based on the status.

7.2 Lighting feedback is intuitive

The mapping between color and state is relatively easy to understand:

• Blue / soft light indicates idle;
• Cyan or dynamic lighting indicates in operation;
• Yellow blinking indicates waiting for approval;
• Green indicates completion;
• Red indicates an error;
• Gray indicates disconnection.

This is more suitable for long-distance perception than reading terminal text.

7.3 Voice prompts are effective for critical states

Voice is most suitable for waiting for approval, task completion, and error status. Especially when waiting for approval, users can easily miss terminal prompts, and voice reminders can significantly reduce the time tasks are halted.

7.4 Clock version has appropriate manufacturing difficulty

Clock version hardware has moderate complexity and can complete the full process in a Fab Lab: 3D printing, PCB, soldering, firmware, communication, assembly, and testing.

8. Which parts are still not good enough?

8.1 BLE stability still needs optimization

BLE is well-suited for desktop devices, but in the Windows environment, issues such as pairing failures, disconnections, or device being occupied may occasionally occur. The daemon process requires stronger automatic reconnection and error prompting capabilities.

8.2 Multi-session information has limited representation in the Clock version

The Clock version mainly relies on lights and voice, and cannot display the full project name, history, and detailed status of multiple sessions. This issue is more suitable to be addressed in the Panel / D-Shell version.

8.3 Voice prompts need to be moderate

If every event is announced, the device will disturb the user. The current strategy is to provide obvious voice prompts only for waiting for approval, completion, errors, and connection changes, while the working status is mainly indicated through lights.

8.4 The housing assembly can still be further optimized

The 3D printed enclosure can already accommodate the main components, but the filament space, speaker opening, screw positions, and maintenance convenience can still be improved.

9. Issues Still to be Resolved

Before final submission, the following issues need to be addressed:

• Should the final version use Clock as the only submitted version, or should it also display the Panel / D-Shell extension?
• What prompt should users see when a BLE error occurs?
• Does the voice file need to support multiple languages?
• Is it necessary to provide a simulated state demonstration mode that does not rely on Claude Code?
• If someone else tries to reproduce the project, which step is most likely to fail?
• Has the license file covered code, hardware, 3D models, and documentation?
• Does the project page clearly state which parts were designed and produced by me?

10. What's next and when?

The arrangements for the final sprint stage are as follows:

Time	Task
First half of Week 19	Organize intellectual property strategies, communication plans, and project progress
Second half of Week 19	Check the final code repository, supplement the README, and organize the license
3 days before the final project	Completed hardware re-test, BLE pairing re-test, voice and light tests
2 days before the final project	Organize 3D files, PCB files, BOMs, and download links
1 day before the final project	Record or edit the final presentation video, and check the presentation images
Final submission day	Complete the final page, presentation review, and defense preparation

The focus of this schedule is to first ensure the stability of core functions, then organize display and dissemination materials. During the final stage, no large-scale new feature additions will be made to avoid introducing new unstable factors.

11. What have I learned?

The most important thing I learned from this project is that the difficulty of a final project lies not only in making a certain module work, but in enabling multiple systems to cooperate stably in real-world usage scenarios.

Specifically, I have learned:

• The value of desktop hardware lies not only in its functionality but also in whether it can seamlessly integrate into the user's workflow;
• The simpler the state protocol, the easier it is to debug and expand the system;
• BLE is well-suited for short-range desktop communication, but disconnection and reconnection must be carefully handled;
• Lighting is suitable for expressing continuous states, while voice is suitable for alerting key events;
• The enclosure design must consider assembly, maintenance, and wire space from the very beginning;
• The weekly skills of Fab Academy will ultimately converge during the system integration phase;
• For an open source project to be reproducible by others, documentation, BOM, license, and downloadable files are just as important as code;
• The final project is not just about "what I did", but also about how others understand, use, and continue to develop it.

12. Final Project Presentation Materials

The final project requires the provision of:

• presentation images;
• presentation video;
• Final Project Page;
• 3D design files;
• 2D design document;
• PCB manufacturing files;
• Bill of Materials (BOM);
• Source code and firmware;
• License description.

Current project code repository:

https://github.com/FreakStudioCN/MicroPython_Claude_Assistant_Public

13. This Week's Summary

Week 19 made me further consider Maker Assistant from a course project into an open-source hardware project that can be disseminated, replicated, and continuously developed.

My plan is:

• Software and firmware are licensed under the MIT License;
• 3D shells, character appearances, and documents are licensed under CC BY-SA 4.0 Creative Commons;
• PCB and hardware materials are organized in the direction of open-source hardware;
• Spread through Fab Academy pages, GitHub, video demonstrations, and maker workshops;
• Explore sustainable revenue through DIY kits, educational workshops, customized equipment, and installation support.

Currently, the project has completed the main functional links, and the remaining focus is on improving stability, organizing documents, clarifying licenses, and completing the final presentation. The goal of this stage is not to add more features, but to make the existing features reliable, clear, and reproducible.

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.