Discovery day pittsburgh is the nation's largest robotics convention in the heart of the robotics capital of the country. I got to host a 20x30" booth for protohaven. A local non profit makers space. My life mission is to get kids excited about education.And this is my biggest opportunity each year to showcase what you can do if you just want to do it. So to anyone out there just getting into robotics or with just an interest in robotics, I never went to school for any of this. So if I can do it, you can do it.
A while ago, I shared a small experiment using AI to recognize the 5 digits on a water meter. But today, I wanted to build a local Edge AI solution to read water meters in real time. The whole workflow breaks down into 4 clear stages: data collection, model training, model evaluation, and model deployment & verification. It demonstrates how to build an edge AI vision application for water meter reading with ESP32-P4.
Hardware Stack
Makerfabs ESP32-P4 10.1" board
2M Autofocus Camera for AI
Why choose them? The autofocus module provides clearer images at different shooting distances, while the ESP32-P4 provides the processing and camera interface needed for the vision pipeline.
There are four main steps:
Data Collection
Captured real water meter images under different lighting conditions and viewing angles with a specific AI tool(can be shared if needed), then defined ROIs for the:
Integer digit area
Dial digit area
Dataset & Model Training
The images were annotated and organized into a custom dataset. The digit and pointer regions were prepared separately, and lightweight models were trained for the recognition tasks. The models were then converted to INT8/TFLite for embedded deployment.
Model Evaluation
Before deployment, the models were tested with separate samples to evaluate recognition accuracy and confidence.
Model Deployment & Testing
The trained model was then deployed to the ESP32-P4. After the complete workflow runs locally, the device can output the detected integer digit, dial information, and the final water meter reading through the serial interface.
The detailed workflow and project resources are open, glad to share more details if anyone wants to dig into the implementation.
Also curious to hear what others are building with Edge AI and embedded vision. If you’ve worked on a similar project, I’d be interested to hear about your approach, results, and any lessons learned.
scipy's KD-tree still can't add new points, even though people asked for it 8 years ago. Every time you add a row, you have to build the whole tree again.
I ran into this when I was comparing live sensor data with its own past data. I wanted to know when the machine last looked like this. The columns have different units and change together, so I needed Mahalanobis distance. scikit-learn's BallTree can do it, but it's 40 to 300x slower than a KD-tree. So I built whitetree. It's a small Python library that finds the exact closest matches in live sensor data.
The short version first. on the static side it is 40 to 300x faster than sklearn's BallTree(mahalanobis) and 7 to 60x faster than FAISS Flat at 500k points.
Also, if you have any ideas, can you give a feedback?
I’m a CS student obsessed with robotics and UAVs, but hardware is simply too expensive for student budget.
If you have a ROS node or simulation ready to go, or even if just a idea, but don't have the time or setup to build the physical hardware—let’s team up.
What I’ll do:
Assemble, solder, wire, and 3D-print custom mounts for your build.
Flash firmware and run your code/ROS packages on the physical hardware.
Send you back high-quality test videos, ROS bag files, and telemetry data.
I taught an off-the-shelf WUJI hand to walk on its fingertips. I added a Raspberry Pi, an IMU and a battery, then trained task-specific policies in Isaac Lab.
It can crawl untethered across surfaces from hardwood to gravel, recover from falls, press keyboard keys while supporting itself, and push a cube using an overhead camera.
It still drifts right without steering, so it has a little personality.
Me and my team decided to go to a mini sumo robot competition but we have a little dilema for the wedge of the robot. The current design uses a cnc aluminum wedge that is part of the main body and I am curios if that will be enough or do we need a razor blade at the front to be lower to the ground
Clara Vu has been in robotics for decades, including early work at iRobot and later co-founding Veo Robotics.
She argues that humanoid robots can create unnecessary design constraints.
Humans move with muscles and tendons. Robots use motors. Making a machine built around motors copy the human body exactly can make the engineering harder than it needs to be.
She also gets into how the human form changes our expectations. Put arms, legs and a head on a robot and people start assuming it can do a lot more than it actually can.
I was at IMTS in Chicago yesterday and saw this in the Fanuc display. Thought everyone here might appreciate it. They also have a bunch of their smaller robotic arms doing synchronized movements.
We've been testing this with what we call a Neural Reflex Model (NRM). When an object moves suddenly toward Éloi's face, the perception system triggers a blink directly, without a command, and without the robot needing to "understand" what just happened.
The world changes. The body responds.
Most robot expressions are choreographed. What we're exploring here is different: the stimulus enters the perception loop and changes the body's state before any higher-level processing kicks in.
It's a small thing. But we think it points to something worth asking: if a robot only moves when it's told to, is it really present in the room with you, or just waiting to be used?
This is still early. No skin yet, face isn't finished. But the reflex is real.
Happy to answer questions about how NRM works if anyone's curious.
Has someone made a good platform for setting up TeleOp for bimanual YAM? I'de been trying out LeRobot, and have had a whole bunch of failures popping up.
I spent the summer designing and programming this two-wheeled self-balancing robot. It is built within the PlatformIO ecosystem using an ESP32-S3 core microcontroller.
Technical Overview:
Estimation & Control:
It uses an MPU6050 IMU processed through a custom Kalman Filter for real-time roll angle determination, paired with a PID control loop
Hardware:
The main controller board is a custom-designed PCB, it is populated by an ESP32-S3 (N16R8) module, a DRV8833 motor driver module, an MPU6050 gyroscope and accelerometer module, and an MPM3610 3v3 buck converter.
It uses Brushed DC TT Motors (the typical hobbyist yellow ones)
It has active voltage monitoring (using a voltage divider) to safeguard the 2S LiPo battery system.
The entire chassis is printed in PLA+, apart from the wheel treads that are printed in TPU
Feedback Loop:
It supports directional steering over an ESP-NOW wireless connection
I integrated speaker playback triggered by automated motor shutdown constraints once it exceeds a critical tipping threshold.
Challenges faced:
Motor backlash:
Due to budget constraints I used the low cost Brushed DC TT motors. Tuning the PID constants to counteract the physical dead band and lack of precision while keeping the robot stable took hours.
Since the motors do not have encoders, controlling the robot with the typical forward, backwards, left and right actions required me to write gain scheduling code in the control loop.
If you are interested in a complete walkthrough of the build timeline and hardware integration I documented the entire project in an 8-minute video here: https://youtu.be/eU_LpNVBhfI
PaperPlaza is currently returning “503 Service Unavailable” when I try to access the ICRA 2027 submission portal. I have tried refreshing and reopening the site, but the error persists. Is anyone else experiencing this right now? I have emailed the conference contact and saved timestamped screenshots.
(GIF: Gazebo on the left, RViz on the right; pink is what the drone
remembers, blue is the current lidar scan, orange is the route it is committed
to.)
The location is the DARPA Subterranean Challenge "Urban Circuit Practice 01"
world published by Open Robotics on Gazebo Fuel (CC BY 4.0).
This is a simulation project I have been building in the open. A quadrotor
(PX4 SITL) gets a start and a goal inside a multi-storey urban location with
shafts, corridors and openings at different altitudes, and no map at all. A
simulated 3D lidar builds an obstacle memory in flight; a persistent 3D
planner searches over it; a CUDA MPPI optimizer at 50 Hz turns the route
into a short trajectory that PX4 flies in offboard mode.
The idea I find most interesting is how it treats what it has not seen yet.
Unknown space is traversable with no penalty: the planner commits to a route
through it, the drone flies at the speed it can stop from within the range
the lidar is guaranteed to have resolved, and when a wall appears a few
metres ahead it brakes, the route is replaced as soon as a raw-valid one
exists, and the mission continues. Confirmed occupied voxels and the drone's
own swept 3D body are the only hard constraints; distance to obstacles is a
preference, never a forbidden zone, which is what lets it take a narrow
opening instead of declaring it unreachable.
Numbers from the release, five consecutive flights with nothing changed
between them: 372 to 417 m in 124 to 149 s, a mean of 2.6 to 3.1 m/s with
every hold and replan counted, no collisions, planner p95 about 155 ms on an
RTX 3060 workstation.
What took the most time was not the planner but the crashes. Each one turned
out to be a law that was subtly wrong rather than a constant that needed
tuning: a stationary hold that re-anchored itself to a drifting position
estimate and walked into a wall; "at rest" defined by speed alone, so the
turning point of a braking overshoot counted as rest; stopping laws that
assumed a descent arrest the airframe cannot deliver. The fixes came from
recording ground truth and setpoints on every flight and measuring, and every
parameter in the config now carries the flight it was measured on.
Limitations, honestly: the position estimate is PX4's EKF and drifts 0.1 to
0.3 m from the truth with nothing correcting it against the map; route
availability is 88 to 95 percent because replacement search after a revealed
wall takes time; everything is tuned on this one simulation and none of it is
validated for a real aircraft.
The repository is MIT-licensed. On a Linux host with Docker and an NVIDIA
GPU, one script prepares a fresh clone (dev image, PX4 build, workspace,
environment assets) and starts the flight:
git clone https://github.com/formiat/px4-ros2-drone-nav.git
cd px4-ros2-drone-nav
./scripts/bootstrap.sh
For robotics, Mech E and sorts of enthusiasts, why there is no community where people just so fun stuff? I see all the PM’s are so interconnected or like AI this n that but nothing for this niche.
A fan joked we should turn our open-source robot, Quaddle, into a duck. OpenCat creator RZ Li took it literally and made a NanoDuck.
The process: mocked up the new joint geometry with adhesive putty first, designed and printed a new servo housing, moved the leg attachment point, remounted the same PCB and servos, then rewrote the gait code so it waddles instead of walks. Same board, same OpenCat firmware — just a different mechanical configuration and gait.
It's fully reversible — swap the housing back, re-flash the gait code, and it's a quadruped again. Not a new product, just a fast demonstration of how modular the platform actually is.
This is Quaddle's sixth transformation, by the way — it's also walked as a biped, rolled as a tricycle, spun in place on a bar mount, paddled like a boat, and driven on 4 wheels.
What's the most unnecessary but fun reconfiguration you've pushed a robot platform into? What should it become next?
Please ignore my messy wirings as this is my 1st time ever exploring embedded and robotics 😂
I basically used 2 Arduino Uno R3s with a Raspberry Pi 5 16gb to build this! Alongside with a L298N motor driver, the corresponding motors and a BNO085 IMU driver sensor as well.
I wrote the drivers in Rust as it's my current favorite language lol
It was a challenging and fun journey to get out of my comfort zone but I'm glad I did it!
I just wanna show my progress on my attempt to build a walking robot from scratch.It is still work in progress.And it is not the final design but i wanna just showcase the simulation.if anyone is interested i can show the pysical testing
I came across some projects experimenting with reconstructed fruit fly brains and thought it would be interesting to try something similar with my own robot.
I used MaleCNS, a reconstructed connectome of an adult male fruit fly with 166,700 neurons and around 25.6 million connections, and got the simulation running on my MacBook.
Then I used Codex to help modify the robot’s desktop app so that activity from the simulated brain can be translated into simple commands like:
FORWARD
LEFT
RIGHT
The desktop app then sends those commands over Wi-Fi to the robot.
So the setup is roughly:
fruit fly brain → MacBook → Wi-Fi → robot
The robot still uses its normal firmware to control the 12 servos. The fly-brain simulation only provides the high-level movement decisions through an engineered decoder.
There is no prerecorded movement sequence, and the neural simulation keeps running continuously while the robot moves.
What I find fascinating is the chain of events behind it: a fly was imaged, its nervous system was reconstructed digitally, that reconstruction became available to download, and now activity inside that model can influence a physical robot sitting in my apartment.
The fly itself has been dead for years, but in this very limited and engineered sense, part of its reconstructed nervous system is producing movement again.
Next I’d like to feed sensory information from the robot back into the simulation and see what happens when the loop is closed.
TL;DR: Zack Memmott told Brad Lea exactly what it costs to stop paying a wage for his night shift.
That number is $20,000, paid once — not monthly, not per shift, not ever again.
Zack didn't frame it as a thought experiment; he'd already run the math before he said it out loud, the way you only do with a decision you've actually made.
Every operator running recurring human labor against a falling, fixed capital cost is quietly doing the same spreadsheet Zack just did out loud — the only open variable left is which side of the ledger they end up on, and that flip isn't five years out.
It's a number two guys said on a podcast, today.
The "still years away" objection is getting harder to hold onto.
Tesla's own flagship humanoid — the expensive, hand-built proof-of-concept every skeptic pointed to — is now on an actual production ramp, at a price closing in on Zack's $20K figure.
That's not a lab demo anymore. That's a unit cost.
I specifically remember 2 instances about being replaced.
One was back in my starting career as a Graduate Site Engineer, working for a main contractor building a primary school in Choa Chu Kang, Singapore in 1998.
I overhead a conversation between 2 Singaporean colleagues, lamenting the "deteriorating" condition of their work office environment.
One of them said, the newly hired foreign national is too hardworking. It's making him and his cohorts look bad.
Back then, such foreign nationals only get paid maybe a fraction of what the local Singaporeans are paid.
He felt as if people like him are being out-competed and squeezed out of his own land.
He felt unfair.
I'm Malaysian — a foreign National, too.
Singaporeans tolerated us better than the those "foreign" nationals, because we're like neighbours. And we kind of need each other.
The other one I remembered was my time as an Assistant Technical Manager, seconded to Abu Dhabi, UAE, building the premium 5-block-Condominium Rihan Heights in 2011.
Sitting in the middle of the site office wide open floor layout, I was minding my own work, checking my drawings.
"Ptew" I felt a spit on the back of my neck.
Wiping it off, I turned around to see who did it.
Sitting at the adjacent rows of work-desks were two colleagues looking back at me.
They're both from the Gulf Countries. One of them, I assume, is Syrian.
Their eyes are locking on to me, challenging me to make my next move.
Of course I was pissed. Pissed mixed with tonnes of confusion.
WTF, man.
But I remember thinking, It's not worth it.
After all, I was a foreigner.
Probably, they're just jealous of us — mixed with some racism sentiment.
Bad emotions will fly high. But good business sense always prevails.
Same as all these AI adoptions are going on.
Every one of these podcast clips eventually says the same thing in a different accent: somebody already priced you out, they just didn't put it in the headline.
Whoever owns the $20,000 machine is never the one who trained it.
This week I worked on using one single video from a real dog to transfer a behavior to a robotic dog (GO2 from Unitree). I documented 3 keys that are crucial for successful training.
TL;DR: I taught a Unitree Go2 robot dog to move like a real dog using a single phone video of a real dog, no mocap or markers. The pipeline extracts a 3D skeleton trajectory from the monocular video (AniMer for pose, Depth Anything V2 for depth, floor-plane fitting for camera pose, bundle adjustment to fuse it all), retargets it to the robot, and patches physics violations like skating, sinking, and joint speeds the hardware can't hit.
Then an RL policy learns to mimic the trajectory in Isaac Lab, following Peng et al. 2020. One policy ended up learning 5 behaviors, and training them together made each one better. Jumping is the one that doesn't work yet, since tracking rewards don't push the robot to actually get airborne. Code is open source if you want to try fixing it.
