Hardware components | ||||||
 |
| × | 1 | |||
 |
| × | 1 | |||
Software apps and online services | ||||||
 |
| |||||
Hand tools and fabrication machines | ||||||
 |
| |||||
 |
| |||||
Hey everyone — Cifer here 👋
This project started as a simple experiment, the kind where you just want to test an idea quickly and see if it works, but somewhere along the way it turned into a full system involving RF tracking, real-time visualization, custom hardware, and eventually… a drone.
The original goal was straightforward:
Build one of the cheapest indoor localization systems possible using ESP32.
Build one of the cheapest indoor localization systems possible using ESP32.
No expensive modules.No complex setups.Just signal strength… and curiosity.
It worked.But not in the way I expected.
Indoor positioning is one of those problems that looks easy until you actually try to solve it, because the moment GPS drops out, you’re forced to rely on indirect measurements that are often noisy, inconsistent, and heavily dependent on the environment.
Instead of going for high-end solutions like UWB or vision tracking, I decided to start with something minimal:
BLE RSSI (Received Signal Strength Indicator)
At a high level, the idea is simple:
- Strong signal → closer
- Weak signal → farther
But in practice, signal strength is affected by:
- Walls
- Objects
- Interference
- Reflections
Which means you’re not measuring distance… you’re estimating it.
Rather than building a quick demo, I wanted a system that actually felt usable, so I split it into three main components that communicate in real time and each handle a specific part of the pipeline.
📡 Tag (ESP32)This is the device being tracked, and its only job is to continuously broadcast a BLE signal so that other devices can detect it.
📍 Anchors (ESP32)These are fixed nodes placed around the environment, and they constantly scan for the tag, measure RSSI, and send that data over Wi-Fi to a central server.
- Fixed positions
- Continuous scanning
- Real-time data transmission
On the backend, a Python server collects RSSI values from all anchors and processes them to estimate position, while a web interface visualizes everything in real time.
- Data collection
- Signal processing
- Live visualization
To estimate a position in 2D space, you need at least three reference points, because each anchor gives you a rough distance estimate, and combining those estimates allows you to approximate where the tag is located.
- 1 anchor → no position
- 2 anchors → ambiguous
- 3 anchors → usable estimate
More anchors = better accuracy.
Once everything is configured, with all anchors connected to the same network and the server running, the system becomes interactive in a way that’s hard to appreciate until you see it working.
You place anchors on the map, define their positions, and after a few seconds:
A green dot appears.
Then you move the tag.
- The dot follows
- It jitters
- It corrects itself
Not perfect.But alive.
⚠️ RSSI Reality — Noise EverywhereThis is where things get interesting, because RSSI is not a clean measurement, and the more you rely on it, the more you realize how unpredictable RF environments really are.
- Sudden jumps in position
- Drift when stationary
- Inconsistent readings
To reduce this, I added calibration:
- Measure known distances
- Capture multiple samples
- Fit a signal model
It helps.But it doesn’t eliminate noise.
🤯 The Turning PointAt this stage, the system was working, but it still felt like a controlled demo rather than something dynamic, and that’s when a simple idea completely changed the direction of the project.
What if the thing I’m tracking isn’t in my hand… but moving on its own?
What if the thing I’m tracking isn’t in my hand… but moving on its own?
Something faster.Less predictable.
So I decided to attach the tag to something mobile.
And that’s where things escalated.
- Control logic
- Communication
- Sensor processing
- Gyroscope data
- Acceleration data
- High current switching
- PWM control
- TP4056 → battery charging
- LF33 → voltage regulation
- Programming
- Debugging
Typing values to control motors. It worked… but it wasn’t usable.
✅ Version 2 — Web ControllerI built a web server directly on the ESP32 so I could control the drone from a browser.
- Phone or laptop control
- No apps needed
- Real-time interaction
- Battery too heavy
- Not enough current
Result: No lift.
🛠️ The Hack- External power supply for motors
Not ideal.Not portable.But enough to keep experimenting.
💡 What This Project BecameThis is no longer just a positioning system or a drone — it’s a combination of RF experimentation, embedded development, and hardware design where every part affects the others.
It’s a platform.
🧠 Lessons Learned- RSSI works, but it lies
- Calibration is essential
- Power systems define hardware limits
- Software is the easy part
Building, debugging, and flying at the same time is chaos.
🧡 Sponsored by NextPCBBig thanks to NextPCB for supporting this project!If you're building your own ESP32-DIV or any other PCB project, I highly recommend NextPCB for fast, reliable, and affordable PCB manufacturing and assembly.
🛠️ Get your boards made here → https://www.nextpcb.com
If you’re interested in building this project, the code and schematic are available on GitHub. Simply visit the GitHub repository to download the necessary files. Feel free to test the code and share your feedback or improvements.
GitHub repository: github.com/cifertech/ESP32-Drone
🚧 What’s Next- Better filtering (Kalman, smoothing)
- More anchors → higher accuracy
- Optimized drone weight
- Stronger power system
- Possibly UWB
This started as a simple idea:
“Can I track something indoors using BLE?”
And turned into:
- A real-time positioning system
- A custom ESP32 drone
- A full hardware + software experiment
Not perfect.Not stable.But real.
And that’s what makes it worth building.
Comments