From a battery-powered monster camera concept to a focused v5 wired room camera.
Project Octopus is a personal hardware and firmware project to build a custom room security camera around a tiny ESP32 camera board, with its own enclosure, electronics, and visual identity.
The original vision was ambitious and very personal:
- create a monster-like camera object inspired by an octopus shape,
- learn Fusion 360 by designing the enclosure from scratch,
- use a 3D printer to turn the design into real hardware,
- build a battery-powered wireless camera that could stay in a room for a long time,
- wake only when motion is detected,
- capture media and send it through Telegram or email.
This repository now preserves that battery-era prototype as an archive while opening a cleaner v5 workspace for the next iteration.
The project was never meant to be only a utilitarian security camera. From the start, the goal was to create an object with personality: something between a creature, a sculpture, and a useful device.
That is where the name Octopus came from. The enclosure explorations gradually moved toward a soft monster or octopus-like form, and that visual identity became part of the motivation for the whole build.
Project Octopus started as a dream project that combined several interests at once:
- embedded electronics,
- camera systems,
- low-power design,
- Telegram automation,
- 3D modeling in Fusion 360,
- physical prototyping with a 3D printer.
The early idea was to create a small wireless room camera using an ESP32 camera module. Over time, that evolved into a more compact board choice based on the seeed_xiao_esp32s3 platform currently used in this repository.
The original v4 concept was built around a battery and a PIR sensor:
- the PIR sensor would stay passive while the main board slept,
- motion would wake the ESP32,
- the camera would take a picture, or eventually record a short video,
- the device would send the result through Telegram or email,
- then it would go back to sleep to save power.
This was the architecture that motivated the electronics work, the soldering, the enclosure fitting, and the firmware that now lives in the archived v4 area of the repository.
By the time the project paused, a lot of real work had already been completed:
- several generations of enclosure and hardware experiments,
- real Fusion 360 modeling and print iteration,
- purchased and assembled electronics,
- soldered prototypes,
- battery voltage monitoring,
- PIR-triggered wakeup design,
- working camera capture and Telegram delivery,
- a physical prototype that proved the main interaction loop.
The project did not stop because nothing worked. It stopped because the most important assumption did not hold up in real-world testing.
The biggest bottleneck was energy consumption.
The dream was for the device to run wirelessly for a very long time, ideally for months, by sleeping most of the time and only waking when the passive PIR sensor detected movement. On paper, that sounded like the right strategy.
In practice, the camera, Wi-Fi connection, and media transfer consumed much more energy than expected. During the first battery tests, the prototype only lasted for a few hours instead of anything close to the multi-month lifetime that had motivated the battery-powered design.
That result changed the emotional energy of the project. The idea was still exciting, but the original architecture no longer felt viable enough to keep pushing in the same direction, so the project was paused for several months.
This is an important part of the story and worth documenting clearly:
v4was not a failure. It was a successful prototype that exposed the real power budget problem.
The v4 phase produced valuable technical and design learnings:
- battery-powered camera products live or die by power budgeting,
- a passive PIR sensor helps, but it does not solve the energy cost of camera capture and network transmission,
- low-power embedded ideas can still fail if the active phase is too expensive,
- enclosure design and electronics packaging are as important as the firmware,
- a prototype can be successful even when it proves that the first product direction is the wrong one.
These learnings are exactly why v4 should be preserved, not discarded.
The next phase of Project Octopus is a deliberate pivot.
Instead of trying to force the battery-powered architecture further right now, v5 moves toward a more practical wired version:
- no battery as the primary power source,
- possibly no PIR sensor,
- a smaller enclosure designed specifically around the tiny ESP32 camera board,
- stable power for 24/7 operation,
- a more practical camera product for daily use,
- a cleaner technical base for a portfolio-quality build and possible future productization.
In other words, v5 is not abandoning the project. It is choosing a more realistic path to make the project succeed.
Project_Octopus/
|- archive/
| `- v4/
| |- Firmware/ Preserved battery-era firmware baseline
| `- Hardware/ Preserved battery-era hardware references
|- v5/
| |- Firmware/ Active firmware workspace for the wired redesign
| |- Hardware/ Active hardware and enclosure work for v5
| `- docs/ Active design notes and decision records for v5
|- docs/
| |- v0/ ... v4/ Historical prototype photos and design snapshots
| `- *.jpeg / *.png Latest v4-era loose renders and prototype photos
`- README.md Project story, archive strategy, and active direction
The repository now keeps both tracks of the project:
archive/v4/preserves the last battery-first prototype as a stable reference,v5/is the active workspace for the new wired direction,docs/remains the shared visual history of the project.
This structure makes it easier to move forward without losing the learnings, code, and hardware context that came from v4.
The previous working prototype now lives under archive/v4/.
Main files:
archive/v4/Firmware/src/main.cpp: battery reading, Wi-Fi connection, PIR handling, Telegram messaging, and wake/sleep flowarchive/v4/Firmware/lib/camera/src/camera.cpp: camera initialization and photo uploadarchive/v4/Hardware/references/: pinout, PIR, and flashing references
- boots the board,
- reads battery voltage from
A0, - initializes the camera,
- connects to Wi-Fi,
- sends a Telegram notification,
- captures and uploads a photo,
- prepares wake on PIR input.
- Wi-Fi and Telegram secrets are hardcoded,
- deep sleep is still disabled for debugging,
- the code is tied to the battery and PIR assumptions,
- there are no automated tests yet.
cd archive/v4/Firmware
pio run -e seeed_xiao_esp32s3The new active development area lives under v5/.
It starts intentionally small:
v5/Firmware/is a clean PlatformIO scaffold for the wired redesign,v5/Hardware/is where new enclosure and hardware decisions should go,v5/docs/is for design notes, decisions, and architecture planning.
- define the wired architecture,
- decide whether the PIR sensor stays in scope,
- design a smaller enclosure around the tiny camera board,
- separate future networking, capture, and streaming decisions cleanly,
- remove secrets from source control everywhere,
- build toward a cleaner portfolio-ready project structure.
The current prototype direction represented in the archive includes:
- Seeed XIAO ESP32S3-based camera board target
- PIR motion sensor
- battery power experiments
- resistor-divider battery reading on
A0 - custom 3D-printed enclosure work
Useful archived hardware references:
If you want to build and test the archived battery-era firmware baseline, use the following workflow.
Recommended options:
- PlatformIO IDE for VS Code
- PlatformIO Core for terminal-based development
Archived target:
- board:
seeed_xiao_esp32s3 - framework:
arduino
Use the following Telegram bots:
@BotFatherto create the bot and get the bot token@myidbotor@userinfobotto get your chat ID
Edit archive/v4/Firmware/src/main.cpp and replace:
ssidpasswordchatIdBOTtoken
cd archive/v4/Firmware
pio run -e seeed_xiao_esp32s3cd archive/v4/Firmware
pio run -t upload -e seeed_xiao_esp32s3cd archive/v4/Firmware
pio device monitor -b 115200The loose images directly under docs/ represent the latest design and prototype state before the v5 pivot.
These images are useful because they show the exact point where the project paused: the device was real, assembled, and visually close to the intended direction, but the energy model still needed a fundamental rethink.
Past versions are archived in docs/ by generation:
docs/v0/: early exposed electronics and proof-of-concept wiringdocs/v1/: first wall-mounted ESP-CAM and PIR assemblydocs/v2/: boxed prototype experimentsdocs/v3/: octopus enclosure exploration, internal fit studies, and CAD analysisdocs/v4/: latest compact battery-era prototype and refinement snapshots
The shared 3D model link stored in docs/README is:
Technical references that informed the prototype:
- Random Nerd Tutorials: ESP32-CAM send photo to Telegram
- Random Nerd Tutorials: ESP32-CAM shield and Telegram example
- Brian Lough / Universal Arduino Telegram Bot
Project Octopus is now entering a better-defined phase.
v4 proved the concept, exposed the power limitations, and created a strong design foundation. v5 is the chance to make the project simpler, more reliable, and more presentable without losing the ambition that made it exciting in the first place.