By Teerath Agrawal
Problem Statement
Ensuring the safety of loved ones—especially children and the elderly—is a constant concern for families. While caregivers want to stay connected and responsive at all times, it is practically impossible to monitor someone continuously. Existing solutions often address only one scenario: either home monitoring or personal safety on the go, forcing users to rely on multiple devices that are costly, complex, and inconvenient. Sentra One is designed to bridge this gap through a dual-mode, 2-in-1 safety solution that adapts to the user’s context instead of requiring the user to adapt to the device.
Mobile Mode – Personal Safety Companion
In its mobile form, Sentra One functions as a compact, lightweight, and low-power personal safety device that can be easily carried or worn. It provides essential safety features such as audio-video feedback with an inbuilt speaker and camera, enabling quick communication and situational awareness. To enhance personal safety further, the device incorporates fall detection, allowing it to identify potential emergencies and trigger alerts. Designed for energy efficiency, this mode prioritizes longer battery life, making it suitable for daily use by children, elderly individuals, or travelers.
Docked Mode – Smart Home Guardian
When mounted on its docking station, Sentra One seamlessly transitions into a more powerful smart home safety and monitoring system. In this mode, the device charges continuously and unlocks extended functionality. The dock includes servo-based motion capability, allowing the camera to cover a wider field of view for enhanced monitoring. With access to the internet, the system can also be programmed to interact with other smart devices in the home, enabling automation alongside surveillance. Audio-video monitoring and speaker-based interaction further enhance its role as a home guardian.
Unified 2-in-1 Experience
The key idea behind Sentra One is progressive functionality—starting as a reliable personal safety companion and expanding into a comprehensive home monitoring system when docked. By combining mobility, automation, and safety into a single modular product, Sentra One reduces the need for multiple standalone devices while offering flexible protection across both personal and home environments.
Why Sentra One is unique
Sentra One is a single device that physically transforms its role based on how it is used.
- Dual-mode by design: Works as a portable personal safety device when undocked and as a powered smart-home monitoring system when docked.
- Same core, expanded capability: Docking adds charging, wider camera coverage via servo movement, and smart-home interaction without changing the device.
- User-driven context switching: No apps or settings—functionality changes naturally based on docking state.
- Consolidated safety solution: Replaces the need for separate personal safety devices and home monitoring cameras.
Components Required
| Component Name | Quantity | Datasheet/Link |
| Adafruit Memento Board | 1 | View Datasheet |
| MG995 Servo motors | 2 | View Datasheet |
| 6 pin pogo connecters | 1 | - |
| MQ-135 | 1 | View Datasheet |
| 5V 2A Adapter | 1 | View Datasheet |
| 16gb micro sd card | 1 | View Datasheet |
| 420 mah battery | 1 | View Datasheet |
Docker Circuit Diagram
Docker Circuit Description
The docking station is designed as a powered extension module that expands the functionality of the Sentra One core device while keeping all control logic within the main unit.
A regulated 5V, 2A external wall adapter supplies power to the dock. The 5V and ground lines are distributed in a star configuration to ensure stable power delivery to all connected components, including two micro servos (pan and tilt) and an MQ-series gas sensor module.To handle current spikes caused by servo movement, a 1000µF electrolytic capacitor is placed across the 5V and ground rails near the power entry point. This bulk capacitor stabilizes voltage during sudden load changes and helps prevent brownout conditions in the main device. Additional decoupling capacitors may be placed near sensitive components such as the gas sensor to reduce electrical noise.
The two MG90S micro servos receive power directly from the 5V rail and are controlled via PWM signal lines routed through the pogo-pin interface to the Sentra One core module. The MQ-series gas sensor module is powered from the same 5V rail and provides an analog output signal back to the core unit for gas concentration monitoring.
A six-pin pogo-pin interface connects the dock to the Sentra One module. The pins carry:
- 5V dock power
- Ground
- Pan servo control signal
- Tilt servo control signal
- Gas sensor analog output
- Dock detection signal
When docked, the main device switches to external power, charges its internal battery, and activates dock-specific functionality such as servo-based camera movement and environmental monitoring. When undocked, the system automatically reverts to mobile mode.
Mobile Mode Description
In mobile mode, Sentra One operates as a fully self-contained personal safety device built entirely around the Adafruit Memento platform. All required functionality is integrated within the main module, eliminating the need for any external components.
The onboard camera, microphone, speaker, wireless connectivity, battery management, and motion sensing capabilities enable the device to function independently as a compact and portable safety companion. Features such as audio–video feedback, event-based recording, wireless alerts, and fall detection are handled directly by the core hardware.Because all sensing, processing, and communication elements are already built into the main unit, mobile mode requires no additional hardware attachments. This ensures portability, reduced complexity, lower power consumption, and ease of use for everyday personal safety applications.
Hardware Assembly
1. Firmware Mode Limitations
During the initial development phase, the primary objective was to program the Adafruit Memento using C through the Arduino IDE. According to the official documentation, the board could be selected as “Adafruit PyCamera S3”, which loads the factory firmware configuration.
When configured in this mode, the onboard peripherals—including the camera, display, buttons, and SD card interface—functioned as intended. The factory example code allowed the device to operate as a standalone camera capable of capturing images and storing them on the SD card. However, this firmware environment was tightly coupled to the board’s predefined functionality. While it enabled core camera operations, it did not provide the flexibility required to integrate extended ESP32 features such as custom WiFi handling, web server implementation, or image transmission over a network.
To overcome this limitation, the board was then configured as a generic ESP32-S3 within the Arduino IDE. In this mode, full microcontroller-level control became available, allowing access to WiFi, Bluetooth, and standard ESP32 libraries. However, this configuration resulted in the loss of direct access to the Memento’s integrated peripherals. The onboard camera, display, and buttons were no longer readily usable without low-level driver integration and custom initialization.
This revealed a fundamental architectural constraint: the Memento platform operates in distinct firmware environments that cannot be used simultaneously. There is no seamless way to switch between factory-integrated peripheral access and generic ESP32 control within a single firmware instance.
As a result, it became clear that the intended development pathway for full hardware support is through CircuitPython, as recommended by Adafruit. However, while CircuitPython provides structured access to onboard features, extending its functionality for a complex, modular system such as Sentra One would require deeper customization and community-level contribution, given the comparatively limited resources and advanced use-case examples available.
This challenge highlighted the trade-off between hardware abstraction convenience and low-level firmware flexibility when working with integrated development platforms.
1. Project Objective
The objective of this development phase was to integrate WiFi-based web server functionality into the Adafruit Memento using Arduino C while retaining full access to the board’s onboard peripherals, including the camera, TFT display, buttons, speaker, microphone, and SD card interface.
2. Development Environment
Board: Adafruit Memento (ESP32-S3 based)
IDE: Arduino IDE
Library: Adafruit PyCamera
Repository: https://github.com/Teerath4/Sentra-One
Two different board configurations were tested:
1. Adafruit PyCamera S3
2. Generic ESP32-S3 Dev Module
3. Configuration 1: PyCamera S3 Mode
When selecting “Adafruit PyCamera S3” as the target board, the factory firmware configuration is loaded.
In this mode:
- Camera initialization works
- TFT display works
- Buttons and speaker function correctly
- SD card image capture operates as expected
On choosing device as PyCam S3 and and "memento_factory_test" code we get the code that runs on the MCU and gives the basic functionality of the device.
The original code can be tweaked a little to display "Hello World" on the display. Code for the below image is saved as "Memento_test_HelloWorld"
The factory example memento_factory_test runs successfully and allows standalone camera functionality.
A minor modification to the example allowed displaying “Hello World” on the TFT screen (Memento_test_HelloWorld).
The tweaked code is available in the GitHub repository.
As far as ive tested this is the only change you can bring to functionality, if u try to add code of esp in this configuration it shows error, for example if I add the code to just say hello world on a webpage running locally on the esp32, it just wont work and show compilation error
This is because the current configuration is of the adafruit pycamera device and not an esp32, I have also added this code to the GitHub repository as "memento_webpage_test" for your reference
However when changed from pycamera s3 to a normal esp32 s3 the webpage code for esp works completely fine, on the contrary the factory code of memento fails to compile
4. Architectural Constraint
The testing phase revealed a structural limitation:
- PyCamera S3 Mode → Full peripheral abstraction, limited firmware flexibility
- Generic ESP32 Mode → Full firmware flexibility, no peripheral abstraction
These environments cannot be used simultaneously within a single firmware instance.
This exposes a tradeoff between:
- Hardware abstraction convenience
- Low-level firmware control
5. Observations
- Factory firmware configuration enables rapid peripheral usage.
- Generic ESP32 configuration enables full networking stack access.
- There is no seamless mechanism within Arduino IDE to merge both abstraction layers directly.
- Achieving full functionality in Arduino C would require manual integration of peripheral drivers outside the factory abstraction layer.
6. Next Phase
The next phase of development will explore:
1.CircuitPython-based development workflow
2.Networking capabilities within CircuitPython
3.Methods for serving SD card images over HTTP
4.Potential ESP-IDF custom build merging PyCamera drivers with full networking stack
Evaluation
This two-week testing phase highlights the firmware abstraction tradeoffs when working with integrated development platforms like the Adafruit Memento.
It demonstrates the engineering constraint between ease-of-use peripheral integration and full microcontroller-level firmware control.
Code Explanation
Memento_factory_test_copy :- is the original test code given by adafruit that defines basic functionality
Memento_test_HellowWorld :- is a little tweaked version of it to display hello world on the display
Memento_Webpage_test :- webpage + memento factory code that fails to compile in the pycamera s3 mdoe
