🧠 The Idea — Indoor Positioning Without GPS
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.

🧩 System Architecture — Keeping It Simple, but Complete
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
🖥️ Server + Web Interface
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
📐 Why Three Anchors?
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.

🧪 Testing — When It Starts Feeling Real
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 Everywhere
This 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 Point
At 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?
Something faster.
Less predictable.
So I decided to attach the tag to something mobile.
And that’s where things escalated.

🔧 Hardware — Minimal Design, Real Constraints
ESP32 — Main Controller
- Control logic
- Communication
- Sensor processing
MPU6050 — Stabilization
- Gyroscope data
- Acceleration data
SI2302 MOSFETs — Motor Driving
- High current switching
- PWM control
Power System
- TP4056 → battery charging
- LF33 → voltage regulation
CP2102 — Communication
- Programming
- Debugging
🎮 Control System — From Pain to Usable
❌ Version 1 — Serial Control
Typing values to control motors. It worked… but it wasn’t usable.
✅ Version 2 — Web Controller
I 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

🧪 Flight Testing — Where Theory Breaks
The Problem
- 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 Became
This 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 NextPCB
Big 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

💻 Code & PCB
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
🎯 Final Thoughts
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.
CiferTech