Projects (6)
AI Voice Assistant — ESP32-S3 Device with Display & Hebrew UI
Embedded AI
Built a standalone push-to-talk AI voice assistant around an ESP32-S3 with a 2.4" color display: it records speech through an I²S microphone, sends it through a cloud speech-to-text → LLM → text-to-speech pipeline, and answers aloud in Hebrew or English while an animated chat interface shows the conversation in right-to-left Hebrew. My focus was the system architecture, hardware selection, wiring, and stage-by-stage integration and testing; the firmware was written with AI assistance.
Designed and assembled a self-contained voice assistant around an ESP32-S3 (N16R8: 16MB Flash, 8MB OPI PSRAM). The board acts as the device’s ears, mouth, and face while the language model runs in the cloud — a deliberate architectural decision, since an LLM needs gigabytes of memory against the chip’s 512KB of SRAM. The audio chain pairs an INMP441 MEMS microphone (I²S, 16kHz) with a MAX98357A Class-D I²S amplifier driving a speaker; the amplifier’s shutdown pin is connected to GPIO 13 so it is powered only while sound is playing, which eliminates idle hiss. A 2.4" ST7789 IPS display (320×240, SPI) shows a chat-style interface with right-to-left Hebrew, a clock, a volume bar, and live animations, and an EC11 rotary encoder sets the volume and starts a new conversation. The assistant can answer questions about weather, news, and time using live web search and an internet-synced clock, and it keeps context between questions. The device was built in stages — microphone, then speaker, then the cloud pipeline, then the display and controls — with each subsystem verified on its own before the next was added. The firmware was written with AI assistance; my role was defining the architecture and requirements, selecting and wiring the hardware, and testing and diagnosing every stage, including tracking a dead display down to a short circuit inside the module itself.
Tech stack: ESP32-S3, Arduino IDE, I²S Digital Audio, INMP441 MEMS Microphone, MAX98357A Class-D Amplifier, ST7789 IPS Display (SPI), EC11 Rotary Encoder, PSRAM, Wi-Fi / HTTPS, OpenAI API, Speech-to-Text, LLM + Web Search, Text-to-Speech, AI-Assisted Development
- Microcontroller: ESP32-S3-DevKitC-1 (N16R8: 16MB Flash, 8MB OPI PSRAM)
- Display: ST7789 2.4" IPS, 320×240, SPI @ 20MHz
- Controls: K0 / BOOT push-to-talk, EC11 knob (volume, 10 steps), knob press = new chat
- Microphone: INMP441 MEMS, I²S, 16kHz
- Amplifier: MAX98357A Class-D I²S, 12dB gain, auto shutdown when idle (GPIO 13)
- Audio Output: 24kHz, 16-bit PCM
- AI Pipeline: gpt-4o-mini-transcribe → gpt-6-luna + web search → gpt-4o-mini-tts
- Languages: Hebrew & English (right-to-left rendering on screen)
- Interface: Chat bubbles, live mic meter, thinking dots, equalizer @ 25fps
- Recording SNR: 30–39 dB
- Response Time: ~10 s from button release to speech
- Firmware: Written with AI assistance
Challenges
- Problem: A language model needs gigabytes of memory, while the ESP32-S3 has only 512KB of internal SRAM Solution: Split the system: the device handles recording, playback, and the on-screen interface, while speech recognition, the LLM, and speech synthesis run in the cloud over HTTPS. The board’s 8MB PSRAM holds the recordings and spoken replies.
- Problem: The first display stayed completely white even though its backlight responded, so it was unclear whether the fault was in the wiring, the software, or the module Solution: Ran an input-only diagnostic scan of the GPIO pins — safe on suspect hardware because it drives no pin — which showed GPIO 1, 4, 6, and 7 changing together, pointing to a short inside the display module rather than in the wiring. The module was replaced, and the new display worked on the first test.
- Problem: Integrating four peripherals — microphone, amplifier, display, and rotary encoder — on one board, where a single fault could hide behind several others Solution: Brought the system up one subsystem at a time and verified each over the serial monitor before adding the next, so every new problem could be traced to the one component that had just been added.
4WD Smart Car — Arduino Multi-Mode Vehicle
Robotics
Assembled, wired, and configured a 4WD Arduino vehicle supporting three control modes: IR remote, autonomous obstacle avoidance, and Bluetooth smartphone control.
Designed and built a fully functional 4-wheel-drive smart car from a component kit — handling the complete mechanical assembly, wiring, and testing end to end. The build includes a dual-layer acrylic chassis with four DC gear motors mounted via T-brackets, an L298N H-bridge motor driver for independent wheel control, an HC-SR04 ultrasonic distance sensor, a TM1637 digital display, and an Arduino UNO running an Arduino Sensor Shield V4.0 for clean GVS-format sensor connections. The car was set up and tested in three configurations, using firmware provided by the course: an IR remote control mode for direct manual driving; an autonomous mode in which the vehicle detects and avoids obstacles in real time using ultrasonic ranging; and a Bluetooth mode that replaces the IR receiver with a BT05 module, enabling full control from a smartphone via the Dabble app. Switching between modes required hardware changes, installing the matching libraries, and uploading the corresponding firmware. All wiring was executed by hand from a circuit diagram with no soldering required.
Tech stack: Arduino UNO, Sensor Shield V4.0, L298N H-Bridge, DC Gear Motors, IR Remote Control, Bluetooth (BT05), Ultrasonic Sensor, TM1637 Display, Arduino IDE, Dabble App
- Microcontroller: Arduino UNO + Sensor Shield V4.0
- Motor Driver: L298N Dual H-Bridge
- Motors: 4x DC Gear Motors
- Distance Sensor: HC-SR04 Ultrasonic
- Display: TM1637 4-Digit Digital
- Control Modes: IR Remote / Autonomous / Bluetooth
- Bluetooth: BT05 Module + Dabble App
- Power: 6x AA Batteries (car) + 2x AAA (remote)
- Libraries: IRremote, TM1637, Dabble
Challenges
- Problem: Several motors rotated in the wrong direction after assembly due to manufacturing polarity inconsistencies Solution: Diagnosed each motor individually under power, identified the mismatched units, and corrected polarity at the H-bridge terminal blocks — keeping each motor on its original output pins to preserve the wiring diagram.
- Problem: Managing 19+ jumper connections across the Sensor Shield, H-bridge, sensors, display, and voltage regulator without errors Solution: Followed the circuit diagram systematically, cross-referencing the G/V/S row labels on the Sensor Shield for every connection, and verified the full wiring before applying power to protect the components.
- Problem: Implementing a second control mode (Bluetooth) that required a hardware swap and entirely new firmware Solution: Disconnected the IR receiver, connected the BT05 Bluetooth module per its dedicated wiring diagram, uploaded the Bluetooth firmware with the Dabble library, and confirmed pairing and control through the Dabble Gamepad interface.
Smart Bin — Touchless Auto-Opening Trash Can
Smart Devices
Built a touchless smart bin with four RF-switchable operating modes, a servo-driven lid that opens in proportion to hand distance measured by an ultrasonic sensor, and a live distance readout.
Retrofitted a standard plastic bin into a fully autonomous smart device by integrating an Arduino UNO with Sensor Shield V4.0, an HC-SR04 ultrasonic sensor, a servo motor, a TM1637 digital display, and an RF 433MHz wireless receiver — all mounted and wired without modifying the bin itself. Running firmware provided by the course, the bin supports four operating modes switchable wirelessly via RF remote: AUTO mode drives the lid open proportionally as a hand approaches within 30cm for smooth, responsive actuation; OPEN and CLOSE modes provide immediate manual override; and LOCK mode freezes the lid regardless of sensor input. The TM1637 display shows a live distance reading at all times. The RF remote was paired by reading each button’s code on the Serial Monitor and assigning it to its mode in the firmware. The servo is mechanically linked to the lid via an internal arm, powered by a rechargeable 18650 lithium battery mounted on the side.
Tech stack: Arduino UNO, Sensor Shield V4.0, HC-SR04 Ultrasonic Sensor, Servo Motor, RF 433MHz Remote, TM1637 Display, NewPing Library, RCSwitch Library, Arduino IDE
- Microcontroller: Arduino UNO + Sensor Shield V4.0
- Distance Sensor: HC-SR04 Ultrasonic (pins A0/A1)
- Actuator: Servo Motor (pin 9)
- Display: TM1637 4-Digit (CLK: 4, DIO: 3)
- Wireless: RF 433MHz Receiver (pin 2)
- Control Modes: AUTO / OPEN / CLOSE / LOCK
- Auto Threshold: 30cm detection range
- Power: 18650 Rechargeable Li-ion Battery
- Libraries: NewPing, Servo, TM1637Display, RCSwitch
Challenges
- Problem: Understanding how a continuous distance reading becomes a smooth, natural-feeling lid motion Solution: Studied the control logic: the 0–30cm sensor range is mapped onto the 50–135° servo range and clamped to the lid’s physical limits, so the lid opens in proportion to how close the hand is.
- Problem: Matching each button on the RF remote to the correct operating mode Solution: Used the Serial Monitor to read the code each button transmits, then assigned the codes to the AUTO, OPEN, CLOSE, and LOCK modes.
- Problem: Creating a reliable mechanical link between the servo and the lid without drilling or permanently altering the bin Solution: Secured the servo inside using double-sided tape and connected its arm to the lid with a wooden stick, fine-tuning the open and close angle values until the motion was precise and repeatable.
Simon Game — Soldered PCB Memory Game
Electronics
Hand-soldered a complete Simon memory game PCB shield for the Arduino UNO — LEDs, push buttons, and buzzer — and brought it to life with the course’s game firmware.
Assembled a fully working Simon memory game by hand-soldering every component — LEDs, push buttons, and passive buzzer — onto a custom Wokwi PCB shield that mounts directly onto an Arduino UNO. The game firmware was provided by the course: each round it extends a random LED sequence, seeded from analog noise on an unconnected pin (A0) so that every game is different. The player must repeat the sequence button by button, and each correct press lights the matching LED as immediate visual confirmation. The buttons use the Arduino’s internal pull-up resistors, so the board needs no external resistors for them. A wrong press triggers a game-over animation — all four LEDs flashing together three times — before the game resets automatically. The sequence supports up to 100 levels.
Tech stack: Arduino UNO, PCB Soldering, LEDs, Push Buttons, Passive Buzzer, INPUT_PULLUP, Wokwi PCB Shield, Arduino IDE
- Microcontroller: Arduino UNO
- Interface: Custom Wokwi PCB Shield (hand-soldered)
- Inputs: 4x Push Buttons with internal INPUT_PULLUP
- Outputs: 4x Coloured LEDs (pins 9–12) + Passive Buzzer
- Max Sequence: 100 levels
- Random Seed: Analog noise from floating pin A0
- Debounce: Release-detection loop
- Game Over: All 4 LEDs flash 3x simultaneously
- Firmware: Provided by the course
Challenges
- Problem: Hand-soldering a multi-component PCB requiring clean joints across LEDs, buttons, resistors, and a buzzer Solution: Approached the board methodically — sequencing components by thermal sensitivity, maintaining a clean iron tip, and inspecting every joint before moving on — producing a reliable, professional-quality result.
- Problem: Understanding why one physical button press can register as several (contact bounce) Solution: Learned that mechanical contacts bounce for a few milliseconds when pressed; the game handles this by waiting until the button is fully released before accepting the press.
- Problem: Understanding how a microcontroller can produce a different sequence on every power-on Solution: Learned that an unconnected analog pin picks up random electrical noise; reading it once at startup provides the seed for the random sequence, with no extra hardware.
Soldering Iron Stand — Parametric CAD Design & 3D Print
3D Design
Designed a custom soldering-iron stand entirely from scratch in FreeCAD — a fully parametric solid model with an angled iron socket, an integrated sponge recess, and personalized embossing — then sliced and 3D-printed it into a working workbench tool.
Modeled a complete soldering-iron stand in FreeCAD using the Part Design workbench, driving the entire geometry from a single dimensioned base sketch and a sequence of parametric features — Pad, Fillet, Pocket, and additional Pad and Pocket operations — rather than loose modeling. The design centers on an angled holder: a socket bored into a face inclined 60° from the base, tapering from Ø40 mm at the opening to Ø36 mm, so the soldering iron seats securely at an angle with its hot tip clearing the base and protruding safely out the front. A Ø50 mm circular recess in the base holds a cleaning sponge, and the name “Idan” is embossed in relief on the side. All outer edges were filleted for a finished look and stronger printed corners. The completed model was exported and prepared for manufacturing in Bambu Studio — orienting the part, checking overhangs, and slicing it — before being 3D-printed via FDM into the functional stand shown here.
Tech stack: FreeCAD, Part Design Workbench, Parametric Modeling, Bambu Studio, FDM 3D Printing, PLA
- CAD Software: FreeCAD (Part Design)
- Modeling: Sketch-driven Pad / Pocket / Fillet
- Base Length: 120 mm
- Holder Angle: 60° inclined socket
- Iron Socket: Ø40 mm → Ø36 mm tapered bore
- Sponge Recess: Ø50 mm circular pocket
- Slicing: Bambu Studio
- Printing: FDM (PLA)
- Personalization: “Idan” embossed relief
Challenges
- Problem: Seating the soldering iron at a stable angle with its hot tip clearing the base and protruding safely out the front Solution: Defined the holder on a face inclined 60° from the base using the angled construction geometry, then modeled a tapered Ø40→Ø36 mm socket bored along that axis — fixing both the resting angle and a firm grip on the iron in a single parametric feature.
- Problem: Combining several functional features — iron socket, sponge recess, side embossing, and filleted base — into one clean solid without geometry conflicts Solution: Sequenced the Part Design operations deliberately (Pad → Fillet → Pocket → Pad → Pocket → Fillet) and attached each sketch to the correct reference plane or face, keeping the feature tree stable and fully editable.
- Problem: Turning the CAD model into a clean, printable part with minimal support material Solution: Prepared the model in Bambu Studio — choosing an orientation that rests the flat base on the bed, verifying overhang angles, and slicing — so the wedge and socket print reliably by FDM without a support-heavy setup.
Quadcopter Frame — Parametric Multi-Body CAD Design
3D Design
Designed a complete quadcopter drone frame in FreeCAD as a fully parametric, multi-body assembly — four arms generated from a single master arm by a polar pattern, a top/bottom plate stack on standoffs, and hardware-accurate motor mounts and electronics bay.
Modeled a full X-configuration quadcopter frame in FreeCAD 1.1 using the Part Design workbench, built entirely from constraint-driven sketches and parametric features rather than freehand geometry. The design is organized as a multi-body assembly: a main frame carrying four arms, a separate top plate, and four cylindrical standoffs that join the top and bottom plates into a rigid electronics stack. Rather than modeling each arm individually, a single fully-dimensioned master arm — complete with its motor-mount hole pattern — is replicated around the central axis with a polar (circular) pattern, so all four arms stay perfectly symmetric and any dimensional edit propagates across the whole frame at once. Each arm tip carries a standard brushless-motor mounting pattern (Ø3.3 mm holes on an 8 × 6 mm grid), and the chamfered octagonal top plate integrates a square cut-out for a flight-controller / camera stack and an oval slot for wiring and a battery strap. Every hole spacing, plate dimension, and standoff position is dimensioned and constrained, so the entire frame is editable from its driving parameters. The feature tree combines Pad, Pocket, Fillet, and PolarPattern operations across the separate bodies, demonstrating a structured, assembly-level parametric workflow. This is a pure CAD exercise — the focus is the modeling methodology and design intent rather than a physical build.
Tech stack: FreeCAD 1.1, Part Design Workbench, Parametric Modeling, Sketch Constraints, Polar (Circular) Pattern, Multi-Body Assembly, Pad / Pocket / Fillet
- CAD Software: FreeCAD 1.1 (Part Design)
- Configuration: Quadcopter X-frame
- Structure: Multi-body (frame + top plate + 4 standoffs)
- Arm Generation: Single master arm × polar pattern (4×)
- Motor Mounts: Ø3.3 mm holes, 8 × 6 mm pattern
- Electronics Bay: Square cut-out + oval wiring slot
- Features: Pad / Pocket / Fillet / PolarPattern
- Modeling: Fully constraint-driven & parametric
Challenges
- Problem: Keeping all four arms and their motor mounts perfectly symmetric while the frame stays fully editable Solution: Modeled a single fully-constrained master arm with its motor-mount pattern, then generated the remaining three with a polar pattern about the central axis — guaranteeing the four arms are identical and letting a single edit update all of them at once.
- Problem: Building a rigid top/bottom plate stack from separate parts that register to each other exactly Solution: Modeled the top plate and the four standoffs as distinct Part Design bodies driven by shared, matching hole-spacing dimensions, so the columns and plates align precisely and the stack assembles without interference.
- Problem: Making the frame accept real hardware — motors, flight controller, wiring — rather than arbitrary geometry Solution: Dimensioned each arm tip to a standard Ø3.3 mm / 8 × 6 mm brushless-motor bolt pattern and sized the top-plate cut-outs (square electronics bay + oval wiring slot) to real component footprints, keeping every feature parametric and hardware-accurate.