Recently, I spent quite a lot of time working on the communication system for the Padma robot.
My goal was simple:
Make it possible for children to control the Padma robot directly from the Padma app.
At first, I thought Wi-Fi would be the better choice.
I already had a kankaung-wifi extension, and I started working on making the ESP32 connect to Wi-Fi and communicate with the Padma app.
I also continued improving the Bluetooth mode at the same time.
So I ended up working on both Bluetooth and Wi-Fi.
And honestly, I was getting excited about the Wi-Fi version.
Wi-Fi gives me a lot of possibilities: WebSocket communication, faster data transfer, easier OTA updates, and more flexibility for future robotics features.
But then I started thinking about something more important.
Who is actually going to use this?
Children.
The Problem I Started Seeing
From a developer's perspective, connecting an ESP32 to Wi-Fi sounds simple.
The ESP32 needs:
SSID
Password
Then it connects to the network.
But for a child using Padma, it becomes something like:
- Create or enable a phone hotspot.
- Find the hotspot SSID.
- Know the hotspot password.
- Configure the ESP32 with those credentials.
- Make sure the phone and ESP32 are on the same network.
- Somehow find the ESP32's IP address.
- Connect the Padma app to that IP.
Suddenly, something that looks simple from the developer side becomes a lot of steps for the user.
And if I have a workshop with many children and many robots, the problem becomes even bigger.
Imagine having 10 or 20 robots in the same room.
Now I have to think about:
- Which hotspot does this robot belong to?
- Which SSID should it use?
- What password?
- What IP address did the ESP32 receive?
- How does the child know which robot to connect to?
- What happens if the hotspot changes?
- What happens if the IP changes?
I could solve these problems.
I started thinking about QR codes, automatic discovery, static IPs, unique robot IDs, UDP discovery, and other solutions.
Technically, it was possible.
But then I realized something.
I was making the system more complicated just to use Wi-Fi.
Bluetooth Was Already Doing What We Needed
The Bluetooth version was much simpler.
The basic idea is:
Padma App
↓
Bluetooth
↓
ESP32
↓
Robot
No router.
No hotspot.
No SSID.
No password.
No IP address.
The child can simply open Padma, select their robot, and start coding.
Of course, Bluetooth has its own challenges.
I had to deal with connection stability, device discovery, write operations, and even problems like messages crossing each other.
I spent quite a lot of time fixing those problems.
But after working through them, I realized that Bluetooth was already good enough for what Padma actually needs right now.
The Important Question
I think this was an important lesson for me as a developer.
I was asking:
"Which technology is better?"
But I should have been asking:
"Which technology is better for my users?"
Wi-Fi might be more powerful.
It might give me more possibilities in the future.
But Padma isn't currently trying to build a high-bandwidth robotics platform.
It's trying to help children learn programming by controlling robots.
For that purpose, simplicity matters more.
So I Made a Decision
For now, I decided to make Bluetooth the main communication method for Padma robots.
The experience I want is:
Turn on robot
↓
Open Padma
↓
Connect to robot
↓
Create blocks
↓
🚗 Robot moves
That's it.
I don't want a child to have to understand networking before they can learn programming.
They should be thinking about:
IF obstacle detected
↓
turn left
Not:
Which IP address did my ESP32 get?
😅
But I'm Not Throwing Wi-Fi Away
One thing I don't want to do is completely delete the Wi-Fi implementation.
I've already spent a lot of time building and experimenting with kankaung-wifi.
And I still believe Wi-Fi will be useful for Padma in the future.
For example:
- OTA firmware updates
- Larger data transfers
- Advanced telemetry
- Camera-related features
- More complex robotics projects
- Future remote-control features
So instead of deleting it, I'm going to keep the Wi-Fi code in the project, but comment it out for now.
The current focus will be:
kankaung-bluetooth
↓
PRIMARY
↓
Padma Robot
while:
kankaung-wifi
↓
FUTURE
↓
Keep developing
This way, I'm not saying:
"Wi-Fi is bad."
I'm saying:
"Wi-Fi isn't the right user experience for Padma right now."
What I Learned
This project reminded me that engineering isn't always about choosing the most powerful technology.
Sometimes it's about removing complexity.
As developers, we naturally enjoy solving complicated technical problems.
I definitely do.
I can spend hours thinking about networking, protocols, discovery systems, WebSockets, IP addresses, and device provisioning.
But sometimes the best solution is the one that allows the user to never think about those things at all.
For Padma, I think Bluetooth is that solution—for now.
And maybe that's one of the most important parts of building technology for children:
Don't make them learn the complexity of the system just to enjoy the thing you're trying to teach them.
Let them open Padma.
Build their blocks.
Press start.
And watch their robot move.
Top comments (1)
The list of things Wi-Fi forced you to design is the real argument: SSID, password, which hotspot belongs to which robot, the DHCP lease, discovery, what happens when the network changes. That isn't connectivity, that's a provisioning system you'd maintain forever — and every rough edge in it lands on a child instead of on you.
We keep hitting the same trade-off on the automation side: the more capable option wins the design review and loses the adoption fight. Not an argument for Bluetooth forever either — for OTA updates you'll be back. Did you measure where the Bluetooth throughput actually caps out for your message pattern, or was that deliberately left open until the feature needs it?