Hardware Architecture Improvement
ESP32 standalone to RPi5 + STM32 architecture migration with ToF + photo sensor to LiDAR consolidation, achieving WiFi stability and ROS2-based simulation/logging capabilities
system
Context
- Products: Wally (horizontal sliding wall), Ceily (vertical ceiling lift)
- v1 architecture: ESP32-S3 standalone (motor control + WiFi/BLE + ToF)
- Sensor configuration (v1): ToF sensor x2 + photo sensor
- Required: person/object detection during movement for safety stop
Core Problem
Sensor Limitations
- Photo sensor cannot detect people during movement
- ToF sensors use ISOSPI, resulting in slow read cycles
- ToF measurement resolution: 4mm
- Two sensors required, increasing hardware complexity
Controller Limitations
- ESP32 running WiFi/BLE/core control simultaneously uses nearly all memory
- Memory shortage causes unstable WiFi connection
- ML/AI expansion impossible (ESP32 resource limits)
- Difficult to log/analyze incidents (ESP32 storage limits)
Key Insight
Solve sensor consolidation and architecture separation simultaneously:
- Single LiDAR can replace all functions of ToF x2 + photo sensor (distance measurement + person detection + zone detection)
- RPi5 + STM32 separation solves memory/logging issues while maintaining real-time performance
Approach
1) Sensor Consolidation: ToF + photo sensor → LiDAR
| Before (v1) | After (v2) |
|---|---|
| ToF x2 + photo sensor | RP LiDAR C1 x1 |
| 106,000 KRW | 90,000 KRW |
| 3 sensors | 1 sensor |
- LiDAR improves distance measurement accuracy
- Angle measurement remains at similar level
- Zone detection added: 360° scan data detects obstacles/people in travel path
- Hardware simplification: 3 sensors → 1
- Cost reduction: 16,000 KRW
2) Architecture Migration: ESP32 standalone → RPi5 + STM32
v1: ESP32-S3 (motor control + WiFi/BLE + ToF)
v2: RPi5 (ROS2 + WiFi/BLE + ML) ←UART→ STM32F446 (motor/Modbus real-time)Role Separation:
- RPi5: ROS2 logic, WiFi/BLE communication, ML/AI (future)
- STM32F446: Real-time motor control, Modbus/RS485, GPIO
Why RPi5 over ESP32 + STM32:
- Native ROS2 support (micro-ROS is limited)
- rosbag for incident analysis (product liability response)
- Gazebo simulation environment possible
- Future ML/vision/voice expansion
Tradeoffs:
| Item | ESP32 standalone | RPi5 + STM32 |
|---|---|---|
| Cost | ~$10 | ~$90+ |
| Power | ~0.5W | ~5.5W |
| Boot | Instant | ~30s |
| ROS2 | Limited | Native |
| Logging | Few MB | Unlimited |
3) STM32 Firmware Reuse
- STM32 firmware remains identical to v1
- Only logic moved to upper layer (RPi)
- Communication via UART protocol
- Real-time performance guaranteed (Linux has low real-time capability)
Results
- Sensor cost reduction: 106,000 → 90,000 KRW (-16,000 KRW)
- Hardware simplification: 3 sensors → 1
- WiFi stability improved: Architecture separation removes ESP32 memory burden
- Incident analysis foundation: ROS2 rosbag can record all topics
- Simulation environment built: Gazebo (ROS2 Jazzy + Gazebo Harmonic) complete
- Extensibility secured: Architecture ready for future ML/AI, SLAM, Nav2
Key Takeaway
- Sensor consolidation achieves cost reduction and functionality improvement simultaneously
- Architecture separation secures stability (WiFi) and extensibility (ROS2/ML)
- Cost/power increase offset by incident analysis capability and simulation development environment
- STM32 firmware reuse minimizes migration burden