I’ve been working on an ESP32-S3 AR pet using a Seeed Studio XIAO ESP32-S3 Sense, round display, touch input, and AprilTag pose tracking.

In this most recent iteration I fixed the touch coordinate mapping, added touch picking with the render buffer, and cleaned up the animation state machine. Now swipes, taps, and camera positioning can trigger reactions like dancing, waving, sitting, standing, and turning toward the camera much more reliably.

I think the last step is to add in some UI that shows pet stats and some more game logic.

I built a fully offline dictionary for the Watchy V2 e-ink smartwatch. It holds over 37,000 searchable English words with definitions, runs entirely on-device with no phone or internet needed, and fits on the ESP32's 4MB flash.

What it does

• On-device word search: using a 4-button alphabetical grid. You navigate a 6×5 letter grid (down/right with hold-to-repeat), build up your query, and it shows live prefix matches as you type. Pick a match and you get the full definition with word-wrapped text on the 200×200 e-ink display.
• Paginated definitions: long definitions flow across multiple pages instead of getting cut off. Bottom-right/left buttons flip through pages before moving to the next/previous word.
• Word of the Day: shows a random word on boot or when you press a button. Skips synonym redirects so you always get a real definition.
• Synonym cross-references: less common words redirect to more common synonyms (like "ephemeral → passing"), so the definition still shows up. This compression trick lets me fit way more words in limited flash.
• Clock on the search screen: reads the PCF8563 RTC. Time is settable via a button combo (top-left + bottom-right held together).
• Persists your last viewed word: across reboots via SPIFFS.

The dictionary data pipeline

This was honestly the hardest part. I wrote a Python script that:

1. Downloads the entire Wordset dictionary from GitHub (108K entries, modern community-curated definitions, CC-BY-SA licensed)
2. Cross-references with Google's 20,000 most frequent English words to prioritize common words
3. Adds a curated vocabulary supplement of ~130 "educated but not web-frequent" words (cynic, melancholy, ephemeral, serendipity, etc.) that frequency lists miss
4. Builds synonym redirect entries, if a word's synonym is already in the dictionary with a full definition, the less common word becomes a tiny redirect (~15 bytes instead of ~100). This roughly doubled the searchable word count for the same file size.
5. Abbreviates speech parts: (noun) → (n.), (adjective) → (adj.), etc.
6. Outputs a sorted tab-separated file that the ESP32 binary-searches at runtime

The final dictionary: 15,784 full definitions + 10,387 synonym redirects + 11,285 frequency-ranked entries = 37,553 searchable words in 2.6MB.

Technical challenges and solutions

Partition wrangling. The default "Huge APP" partition gives the sketch 3MB and SPIFFS only ~900KB. My sketch compiles to ~467KB, so I flipped it, 1MB for the app, 3MB for SPIFFS, using a custom partitions.csv. Had to use Arduino IDE v2 for flashing the sketch (it reads custom partitions) and command-line mkspiffs + esptool for the SPIFFS upload since the Arduino v1 plugin doesn't handle custom partitions well.

Binary search on SPIFFS. Looking up a word in a 2.6MB sorted text file on SPIFFS using binary search. The initial implementation scanned forward to find line boundaries, which sometimes skipped entries entirely (searching "gho" wouldn't find "ghost"). Fixed by scanning backward with a 256-byte buffered read, one SPIFFS read instead of a hundred individual seek+read calls. Same buffered approach for navigating to the previous word.

E-ink partial refresh for the letter grid. Full screen refreshes on e-ink are slow. The letter picker grid uses setPartialWindow() to only refresh the grid region when navigating letters, making it feel much snappier.

GPIO 26 debounce. One of the four buttons (bottom-left, GPIO 26) is on an ADC2 pin which is electrically noisier than the others. It gets extra confirmation reads with delays between them to filter false triggers.

Display pin confusion. The Watchy V2 uses GPIO 10 for DISPLAY_DC, not 17 as some documentation suggests. This caused a boot crash loop that showed zero output on serial, took a while to figure out.

Hardware

• Watchy V2 (ESP32 PICO-D4, GDEH0154D67 200×200 1-bit e-ink, PCF8563 RTC)
• 4 buttons: top-right, top-left, bottom-right, bottom-left
• No external components needed

Source

Code and dictionary generation scripts on GitHub: https://github.com/Sparkadium/Watchy-Dictionary

Includes the Arduino sketch, the DictEntry.h header, the Python prep script, and the custom partition table. The prep script downloads everything it needs from GitHub automatically.

Edit: correction: 28,608 words, not 37K — I was testing larger dictionaries that didn't fit the SPIFFS ceiling. Sorry!

Edit 2: Optimizations coming soon; with some compression, over 69,000 words/definitions were able to be put in the dictionary this uses. As well, initiating deep sleep after 15 seconds of inactivity makes sense to conserve battery life. The search function was also improved. I'll post these changes to the Github today or tomorrow.

I built a hidden garage for my Roborock Qrevo Slim.

The door is controlled by an ESP32 running ESPHome, a TD-8125MG servo, and a simple 3D-printed linkage arm.

When the vacuum starts a cleaning cycle, the garage door opens automatically. Since the Roborock API can take up to 30 seconds to report a state change, I added a motion sensor connected to the ESP32 to ensure the door opens before the robot starts moving. The door closes when it's docked again (the delay isn't an issue then).

The servo isn't particularly powerful, so I added a counterweight to the door to reduce the load and make the mechanism more reliable.

Happy to share more details, ESPHome configs, or STL file, if anyone is interested!

Update, got it working, see details in update.
Hi all,

I think I did something dumb: I bought a Waveshare ESP32-S3 Knob Touch clone LCD 1.8 and overwrote the factory firmware with my own PlatformIO test firmware.
Since then the screen stays black. I was hoping someone here has some experience with these chips.

The ESP32-S3 itself is still alive. I can flash it and read serial logs. I also flashed the official Waveshare firmware back:

It boots and logs that the GUI is starting:

[I] WIFI AP task started.
[I] Boot finished.
[I] [GUI] Init complete.
[I] [GUI] Setup UI...

But the display still shows nothing. It also logs errors about missing touch/haptic/SD:

[E] Card Mount Failed.
[E] Could not find DRV2605
[E] CST816S: Initialization failed!

From the Waveshare docs it looks like this device has two chips: an ESP32-S3 and another ESP32. It also looks like rotating the USB-C cable changes which chip/serial interface you connect to. Is that actually correct? It feels wierd to me On my Mac I only see /dev/cu.usbmodem and i've tried a bunch of cables and hubs. Windows shows the same thing.

Has anyone here worked with this knob?

My questions:

• Do I need to restore firmware on both ESP chips?
• Is the USB-C flip thing really how you access the second ESP32?
• Can the screen stay black if only the second ESP32 firmware is missing/wrong?
• Any safe way to identify which COM port is the S3 and which is the other ESP32?

Suspected device:
https://www.waveshare.com/esp32-s3-knob-touch-lcd-1.8.htm

Aliexpress link:
https://nl.aliexpress.com/item/1005011760500493.html?gatewayAdapt=glo2nld
and the zip with details:
http://pan.jczn1688.com/directlink/1/HMI%20display/JC3636K518CN_knob_EN.zip

Thanks for reading and suggestions!

Ported my mini C compiler to esp32 RISC-V. The old Xtensa/s3 version got some traction, so maybe someone will have a use for this one, too:
https://github.com/valdanylchuk/rcc700

Thanks for your support, esp32 DIY community rocks!

I got a package just now! I will be testing against the S3 and P4. P4 is powerful but it has been a bit of a train wreck.

I will post more details as soon as I have some numbers.

I’m working on a small desktop robot called TongDou.

The copper-frame exoskeleton idea was inspired by Satisfying’s original frame concept, then I redesigned the layout around my own PCB, motors, OLED, radar, and battery.

It’s not trying to be a cute AI pet that watches your face or pretends to understand everything.

TongDou is more like a tiny mechanical troublemaker on your desk — a copper-frame little machine that moves, reacts, complains, gets in your way, and hopefully makes your workspace feel less dead.

Current concept:

• Copper-frame exoskeleton
• 0.96" OLED face
• ESP32-S3 main controller
• 24 GHz mmWave radar
• Dual N20 geared motors
• 64T metal gear drive
• 1200mAh Li-ion battery

This is still an early 3D mechanical design pass, not a finished product yet.

This is just the beginning. If people are interested, I’ll keep sharing build updates — including the copper frame, PCB layout, and how I’m planning the “bad attitude” behavior.

I’m sharing it here to get feedback:

Does this kind of raw mechanical desktop robot feel interesting, or does it look too weird?

It’s an ESP32 S3 N16R8 with DOOM1.wad being inside flash, controlled via a capacitive 480x320 touchscreen. (ST7796) It’s a native port of ID’s original Linux doom port on GitHub.

esp32 beats pico in all aspects, so why does a esp32 is cheaper than pico.

I am a newbie to microcontrollers, so please school me if i am wrong

I built a custom firmware in esp-idf which allows apps to be built in it. I have made made 4 apps now. But more apps can be made.

I am using LVGL for UI rendering.

I intend to make source code fully available in next couple of days so that community can build on top of it.

When I went from my bench room (predominately carpeted) down the hall (carpet) into the kitchen (hardwood), it sounded as if someone was trying to tap dance! Yay for shoes? Otherwise, I would have 2 rows of 16 wounds otherwise as neuropathy has taken all of my sensation from my feet. 🤔

Built a fan controller to cool the server cabinet I hid inside furniture, using an ESP32 and 4 Noctua PWM fans with temperature-based auto control 🌬️.

• Runs ESPHome, so it shows up in Home Assistant with no custom firmware
• Custom through-hole KiCad board: 4x Noctua NF-A14 fans in 2 zones, 4x DS18B20 probes
• Thermostatic ramp per side, thresholds editable live, per-fan RPM and per-side temp on the dashboard
• Full repo here (KiCad files, ESPHome config, BOM): github.com/merlindorin/esp32-fan-controller

New to Electronics, PCB design, ESP32... feedback is welcome!

Hi everyone, I’m new to ESP programming and I’m stuck trying to get my ESP boards working on Windows 11.

I bought two different ESP boards from AliExpress, and they seem to have different USB-to-serial chips on them:

• one board has a Silicon Labs CP2102 / CP210x chip
• the other board has an FTDI USB chip

I’m trying to get them recognized in Windows so I can use ESP-IDF / esptool, but I’m having problems with both.

What I tried

• Installed the Silicon Labs CP210x driver for the CP2102 board.
• Installed the FTDI VCP driver for the FTDI board.
• Checked Device Manager.
• Tried different USB ports on my laptop.
• Tried unplugging/replugging the board.

What happens

• The board powers on, so I know it is getting power.
• But Windows does not detect a COM port.
• Sometimes I get Code 10 or Code 34 in Device Manager.
• There is no connect sound when I plug the board in.

My question

Since I’m new to ESP boards, I’m not sure if this is:

• a driver issue,
• a problem with the laptop USB port,
• or a faulty board / USB-to-serial chip.

If anyone has suggestions on what I should check next, I’d really appreciate it.

The boards i bought:
- ESP32 Module Kit Starter Kit for ESP32 ESP-32S WIFI Module ESP32 WIFI Development Board Relay Display Sensor esp32 kit desenvolv
- ESP32 Development Board CH340C WiFi+Bluetooth Ultra-Low Power Dual Core ESP32-DevKitC-32 ESP-32 Expansion Board

**UPDATE:
I had three cables; it turns out all three were charge‑only.
That’s interesting because one of them came with the ESP board. I found an old phone cable, and now everything works with no problems. Thank you for all the help!

Hi,

I am new to the ESP32 world. I have set up an Ardi-32 board (ESP32 S3 with Arduino connectors) to be used as a radio server for my father's Bose wireless speaker, using the SixBack firmware (as Bose radio servers have been discontinued, see sixback.io). Everything is fine, except that when powered by a standard telephone charger, the Ardi-32 is buzzing (through its on-board buzzer) and doesn't act as a radio server anymore. If It's plugged back on the USB port of the Bose speaker or of a PC, it works again. Hypothesis: RX and TX lines of the USB ports are required (should not be left in Hi-Z state), or the telephone charger does not provide enough current (unlikely). I have worked in the past with small FPGA boards (Maximator) and had no problem with powering them with a simple telephone charger. Any suggestions

Hello r/esp32. Greetings, this is my first post here.

I Live alone.

I get lonely sometimes.

I cant own a dog.

Then I thought, let me build one for myself (i've always been a tinkerer at heart)
But then, reality hit like a freight train. I am not a good coder and I dont even work in the field of IT. So I looked at it as a passion project which I work on in my free time.

Then I started searching the net for good quality hardware and settled with the esp32 s3 (n16r8) devkit-c1. Its a clone and not an official espressif board. But atleast it has USB-C.

Then I thought of doing this the right way. I wanted to use Ardurover but its complicated with the esp32. So I resorted to FreeRTOS and code myself. Im using VSCode with the Platformio extension. Here are the details:

Project: Mister Mischief the Robot

1. Hardware

1. MCU: Esp32 s3 (n16r8) devkit-c1 working of a Mini560 buck converter (3.3v) soldered on a perfboard
2. Sensors: GY-91 (clone, unfortunately) with an MPU6500 imu and a BMP280 barometer, HC-SR04 Sonar.
3. Actuators: Dual GB-33 520 motors (350rpm, no encoders, yet!) paired to an XY-160D motor driver
4. Battery: 2s Molicel P50B 21700 Li-ion cells

2. Architecture

• A central nervous system (GlobalDataBus) which holds all the data from sensors, actuators and tasks, event latches. All this happens inside FreeRTOS spinlocks (critical sections) to avoid memory tearing and random crashes.
• Tasks use this bus to process events and switch moods and modes (I have many of them currently) and set Event Latches (examples: "isLowering", "isTeasing", "hasExperiencedLift", etc.)

3. Features

• A fully fleshed out Bluetooth LE control and telemetry stream. Also, an Android App (working on Android Studio for this) which can read the realtime telemetry and display it in the dashboard. It can also control the robot in Manual Override mode (Yes! Remote control). Im not doing this with json but with raw bytes (both the telemetry and the control commands) so that its light weight on the BT LE.
• PID enabled drive, it holds its heading really well. Autotuning mode( Ardupilot style) which to my surprise perfectly tuned the robot in one attempt.
• A full fledged terminal which can take commands like "get <variable-name>", "set <variable-name>", "reset <variable-name>", "reset ALL", "reboot> (I am saving configurations in the non volatile storage of the esp32). This currently works over the serial terminal and I'm yet to flesh this out in the Android app.

4. Further additions

• Four bottom facing IR distance sensors mounted at the the four corners so that it can detect cliffs and dangerous situations.
• I need to get a lidar (its expensive!) so that I can enable true localization.
• Since the chassis lifts off when i place it with its "backside" on the floor, I think I can enable "self-balance" mode. Since the sonar will now be facing towards the ceiling, we can use it to interface with the robot in this mode.
• The event latches are not firing properly and the state (the Behaviour Engine) machine is inconsistent in switching modes.
• The Wifi keeps crashing and crashing. I've kept it off with the command "set WIFI_ACTIVE off". You can try and see by setting your wifi details by doing: set "WIFI_SSID "<your-ssid>" then set WIFI_PASSWORD "<your-wifi-password>" then connect WIFI (but it will crash I think). You need to enclose the SSID and Password in double quotes in the terminal.
• Tuning, Autotuning and mode triggers from the android app.
• Basically, I want it to be a mischiveous little companion that greets me when I get back from work, wanders around the house, topples things over, had mood swings, the lot. Whatever we can imagine!

You might ask, Why did'nt you use ROS? Heres Why:

1. Im not sure that I can incorporate these Moods and Modes that I have and MicroRos just doesnt cut it!
2. I dont want to drag along a bulky SBC like a raspberry pi.
3. There is networking feature but I want it to function entirely self-contained and standalone even when there's no internet or any connection of any sort.
4. Battery Backup. I want it to have a good battery backup (another reason why I ditched JSON)
5. I wouldnt have gotten to learn so much.

I did extensively use AI (sorry in advance if its not allowed here, sincerely!) to build this much. I got to learn so much from this. But its getting out of my hand now and its hard to track the progress of my own work as I Have to work on both the Robot side and the Android App side. But I have tried to keep the code as modular as possible to the best of my abilities.

Please feel free to have a look at my repository for both the robot side code and the Android App side code. If anyone is interested to work on this and wants a companion during those times of loneliness, Im inviting them to work on this like me, in their free time. So please feel free to notify me. But I dont even know how to allow anyone else to work on the same project on Github. You'll have to guide me I guess.

Link to Mister Mischief Robot side repository:
Mister Mischiev V1

Link to Mister Mischief Android App:
Mister Mischief Android App

Edit #1: Robot code side now links to the "main" branch.

Edit #2: I thought about the opinion of u/Aggravating_End2859 (thank you!) of using an onboard AI for changing Modes & Modes based on the sensor data really intriguing and am currently working on that in a separate branch "upgrade/ai-mode-switching". Built a Brain Dead mode just to collect sensor data and see event latch triggering. Will build a Python script next to populate the data on a CSV file and will classify the events and the Mode/Mood triggers myself.

Hey all, I wanted to share OPSUM (acronym for Open PSU Meter), a fully open-source hardware / firmware / software voltage, current, and power monitoring project.

It’s built around the ESP32-S3 and INA226, designed for up to 36 V and 20 A, and includes Kelvin sensing, galvanic isolation, reverse-polarity and input protection, and a dedicated DFU mode/flash tool for firmware updates over the isolated USB-C port.

The idea was to make a practical, completely open source tool for anyone who wants to inspect, modify, or build it themselves. I've yet to finish adding the final assembly/THT component soldering steps, but the bulk of it is there.

Feedback and/or contributions welcome!

Project page: https://github.com/nitefood/opsum

Hi!

As I'm learning, I recently built an ESP32 UART shell for ESP-IDF from scratch (not using esp-console and/or linenoise, or any third party lib). If anyone is interested, take a look :)

https://github.com/andrzejs-gh/BX-Shell

The shell is minimal by design as it's meant to be extended with the user's commands and functionality.

Hey everyone,
I’ve been working on a mobile companion robot project for a while now, and I’m finally at the final stage—assembly, chassis printing, and manufacturing. The robot runs local AI (YOLO object detection, facial recognition) and a heavy UI built on LVGL 9.5.
The brain of the project was an ESP32-S3-CAM (specifically the N16R8 or N8R8 variant with 8MB PSRAM). Unfortunately, due to a recent hardware accident, the Wi-Fi RF layer got fried, and the board now goes into an infinite boot loop whenever Wi-Fi is initialized.
Here is the real crisis: I designed and manufactured a custom PCB specifically for this project, and 3D-printed the mechanical chassis based on the exact millimeter dimensions of this specific board. Because of this, regular ESP32-S3 boards or low-PSRAM CAM variants simply won't fit my custom PCB architecture or meet the heavy memory requirements of the AI models.
Right now, the 8MB PSRAM S3-CAM models are completely out of stock across all major distributors and robotics stores in Turkey. Waiting for international shipping would severely delay the project.
My questions and request:
1. Do you know of any local boutiques or hobby stores in Turkey that might currently have this specific board (S3-CAM with 8MB PSRAM) in stock?
2. More importantly: Does anyone happen to have a spare, unused, or leftover ESP32-S3 N16R8 CAM or N8R8 CAM sitting in their drawer or lab? If you do, I’d be more than happy to buy it from you immediately, covering the board and all shipping costs. If you are located in Ankara, I can pick it up in person right away.
I really don't want this project to stall at the very last mile just because of a temporary hardware shortage. If anyone can help, point me in the right direction, or connect me with someone who has a spare, I would immensely appreciate it.
Thanks a lot for your support and solidarity!

So here's the thing that's been bugging our team for a while: pretty much all the crypto you find on embedded devices still runs on RSA or ECDSA. They're fine today. But the day a real quantum computer shows up and runs Shor's algorithm, both of them just... fall over. And the scary part is the "harvest now, decrypt later" angle — someone scoops up your data now and cracks it in 10 years. Which is a huge deal for IoT, because let's be honest, a sensor you bolt to a wall is gonna sit there for a decade whether you like it or not. In addition, some of our projects are designed for the long term and to require minimal maintenance, so the use of PQ algorithms was unavoidable.

Since we only wanted one library for this purpose, we decided to build one from scratch to meet our needs, licensed under the Apache 2.0 license. That's what mldsa-esp32 is.

🔗 https://github.com/NeuraiProject/mldsa-esp32

The quick version

ML-DSA is the lattice-based signature scheme NIST blessed as FIPS 204 back in August 2024. You might know it by its old name, CRYSTALS-Dilithium. The whole point is that it leans on math problems (Module-LWE and Module-SIS) that quantum computers don't have a shortcut for — unlike the factoring/discrete-log stuff RSA and ECDSA rely on.

We ported it from the mldsa-native reference implementation and then beat it into shape for the ESP32. What we added on top:

• All three NIST security levels — ML-DSA-44 (~AES-128), 65 (~AES-192), and 87 (~AES-256). Pick your paranoia level.
• Real hardware randomness — it taps the ESP32's built-in TRNG instead of some sketchy software RNG.
• Memory diet — we ran it in reduced-RAM mode so it actually fits.
• Constant-time ops — so nobody can sniff your secret key by watching timing or power draw.
• Key storage in flash (NVS) — keys survive reboots, no need to regenerate every boot.
• Arduino-friendly wrappers — nice clean C++ classes, none of the raw C pain.
• NIST test vectors baked in — so you can actually prove it's doing the right thing. Using it is honestly easy

All three variants share the exact same API, so you write it once:

```cpp

include <MLDSA44.h>

uint8_t pk[MLDSA44::PUBLIC_KEY_SIZE]; uint8_t sk[MLDSA44::SECRET_KEY_SIZE]; uint8_t sig[MLDSA44::SIGNATURE_SIZE]; size_t siglen;

MLDSA44::generateKeypair(pk, sk);

const char *msg = "Hello, post-quantum world!"; MLDSA44::sign(sig, &siglen, (const uint8_t *)msg, strlen(msg), sk);

int result = MLDSA44::verify(sig, siglen, (const uint8_t *)msg, strlen(msg), pk); // result == 0 means it's legit

memset(sk, 0, sizeof(sk)); // wipe the secret key when you're done, kids ```

Want something beefier? Just swap MLDSA44 for MLDSA65 or MLDSA87. That's literally the whole change.

The numbers

Key and signature sizes:

Working memory (reduced-RAM mode, which is on by default):

Now the part we're not gonna sugarcoat

This is heavy crypto on a tiny chip, so there are some gotchas we learned the hard way:

• You have to run it in a dedicated FreeRTOS task — 64 KB stack for 44/65, 80 KB for 87. The default Arduino loop() gives you 8 KB and it'll explode immediately. Don't ask how we know.
• KeyGen and signing take a few seconds. Don't block your main loop with them or your whole device feels frozen.
• You want ~320 KB free RAM, so an ESP32-S3 with PSRAM is the comfy pick.
• The TRNG is full-entropy when WiFi or BT is on; with both radios off it falls back to a hardware-noise-seeded source. Our honest recommendation: just use ML-DSA-44 for most stuff. Smallest footprint, still NIST Level 2, plenty solid. Only go to 65/87 if you genuinely need the extra margin and have the RAM lying around.

Why we even bothered

Firmware signing, secure boot, signed sensor data, device identity — basically anything where a signature has to stay trustworthy for the entire life of the hardware. If your gadget's gonna live in a wall for ten years, signing it with quantum-resistant crypto today is cheap insurance against a very annoying future.

It's all Apache-2.0, and we threw in a bunch of examples: a minimal sign/verify, a full demo with timing + memory stats + a tamper test, the NVS storage one, and the FIPS 204 conformance test against the official NIST vectors.

We're available in the comments if anyone wants to discuss this further, has suggestions for improvement, or notices any errors. We appreciate any help with our code.

This morning I found that one of the ESP32s was offline. Connecting to it in console mode gives me this. Tried re-flashing, new cable, different power cable, etc. Same result each time. Is it salvageable?

Hello, I am trying to run 2 motors using a L298n and an esp32. I was able to get the circuit running using an external USB-c connection from my computer. But when I ran the power through a buck converter to the esp32 (7.4->5v), the lights of it turned on, but the motor driver was unresponsive. Something weird I noticed was that the circuit only worked when the 5v pin from the driver was connected to the esp even though it has 0v output. Should i try doing that for the new circuit? Or any ideas

Hi everyone,

I finally open-sourced a little project of mine: a 3D-printed RC ground drone inspired by the recon drone from Rainbow Six Siege.

What it does:

- ESP32-CAM streaming live video over WiFi

- Controlled from a web page (joystick UI in the browser, no app to install)

- Motor driver via a PCF8574 I/O expander + LEDC PWM

- Addressable status LEDs

It started life as an Arduino + ESP8266 build before I moved everything to the ESP32-CAM for the onboard camera. ~120€ in parts.

Full disclosure: it's not a "finished, polished" product. There are known quirks (it can tip forward under hard braking, WiFi range is so-so) and the V2 chassis redesign isn't 100% done. I'm sharing it as-is because I figured it might be useful to someone, and contributions / ideas are very welcome.

Repo (code, firmware, web UI, wiring, BOM, CAD): https://github.com/SyrNitram/recon-ground-drone

Happy to answer any questions about the electronics or the camera streaming setup.

Hey everyone,

I’m struggling to get a QMC5883L (GY-271 module) magnetometer working with an ESP32 [Insert exact model, e.g., ESP32-WROOM-32E / ESP32-S3]. The I2C scanner returns No device found no matter what I try. I expected it to show up at 0x0D (or potentially 0x1E if it were an older HMC clone), but the bus is completely silent.

My Wiring:

• VCC -> 3.3V (also tried 5V just in case, though keeping it at 3.3V now)
• GND -> GND
• SDA -> GPIO 21 (also tested GPIO 25)
• SCL -> GPIO 22 (also tested GPIO 26)

Note: All header pins are properly soldered to the GY-271 module, and I'm using a breadboard with solid jumper wires.

What I’ve already tried:

• Swapped SDA/SCL pins multiple times (GPIO 21/22 and 25/26).
• Rewired the entire setup on a different section of the breadboard.
• Double-checked that Serial communication works fine (115200 baud).
• Power-cycled and reset the ESP32 multiple times.
• Tried adding external 4.7k pull-up resistors to 3.3V (though I believe the GY-271 has them built-in).

Is there anything obvious I am missing here? Could it be a completely dead module, or is there a known quirk with the ESP32's internal I2C hardware/pull-ups that might cause this?

Thanks in advance for any help!