u/Ok_Stress3654

I posted a few tests of this lamp here before and got a lot of really useful feedback, so I tried to put it into practice this time.

This one took me about 12 hours to animate and shoot. All the motion was animated beforehand in my own editor using keyframes - nothing is puppeteered during filming.

I also added a rig and FK/IK controls to the editor after people here suggested it, which made working with the lamp a lot easier.

I tried to pay more attention to timing, anticipation, pauses and making the movements actually feel intentional this time.

Would love some critique. What would you change?

A small update on my robotic lamp project.

This time I wanted to make a little bowling scene, so I modeled and 3D printed a few “I”s for him to knock down.

Completely normal choice of bowling pins. No particular reason for it 👀

Printed in PLA.

I’m adding basic object recognition to my robotic lamp. It runs on a Raspberry Pi 5 and has an RGB-D camera in its moving head.

I’d like to run object detection in the background while the lamp is active and gradually build a map of the objects around it. Since the base stays in place, I can calculate the camera pose from the joint angles. My plan is to combine detections from the RGB image with depth data, transform the object coordinates into the lamp’s base frame, and save their positions and last-seen time. Repeated detections would be merged so the map doesn’t fill up with copies of the same object.

Which lightweight object-detection models and inference runtimes would you recommend for a Raspberry Pi 5? A high frame rate isn’t necessary, but I’d like reasonable detection quality for common objects. I’d also be interested in approaches for reliably matching the same objects across observations.

The current Raspberry Pi and ROS 2 architecture is described here:

https://github.com/Nikolay-Tyulkin/Watti/blob/main/docs/ARCHITECTURE.md

Hi! I’ve recently started experimenting with reinforcement learning in Isaac Lab. My goal is to teach this robotic lamp different ways of moving, including balancing, locomotion and eventually jumping.

I already have a basic training setup running, but getting useful behaviour from such an unusual mechanism is proving harder than I expected. Most of the materials I’ve found are built around humanoids or quadrupeds, and I’m still fairly new to RL.

Are there any guides, papers, repositories or general approaches you’d recommend for training locomotion on a custom non-humanoid robot?

The video shows one of my very early jumping experiments.

I ran a preliminary test to see how consistently Watti could return to the same position.

Across 10 repetitions, the average measured deviation was about 0.03 mm. This was only a simple test at one position using a dial indicator, but the result was better than I expected.

Next, I want to experiment with using her depth camera and movement to create 3D scans of the surrounding scene and individual objects.

After several iterations, I’ve finally finished the 3D-printed enclosure, including the base. The lamp now looks like one complete character rather than an open prototype.

I also redid the cable routing, reassembled all the wiring, and added a power switch on the back.

And the lamp finally has a name: Watti.

Sorry for Party Rocking!

I’ve briefly shown earlier versions of the editor in my previous posts, but this video gives a closer look at the complete workflow.

This is Watti, my five-axis robotic lamp, and Watti Studio, the browser-based editor I built for creating its movements and lighting scenes.

I’ve also refined the enclosure since my previous posts. It now looks cleaner and is much closer to what I imagine as the final design.

In the video, I create a scene on the timeline, preview it on the virtual robot, and then run the same scene on the physical Watti. During playback, the real robot appears below the simulation so their movements can be compared directly.

Motion and lighting share the same 25 Hz timeline. The complete scene is uploaded to a Raspberry Pi 5 and played locally through ROS 2, so the browser doesn’t need to remain connected during playback.

I’ve also made the project repository public:

https://github.com/Nikolay-Tyulkin/Watti

There’s no source code yet, so it’s currently a public project preview rather than an open-source release. The repository already contains more extensive information about the architecture, hardware, current capabilities, and roadmap. I’ll also use it as a public development tracker, so anyone interested can follow the project’s progress.

I’d be interested to hear what you think about the workflow and what features you would find useful in an editor like this.

A small update on my robotic desk lamp: the entire control system now runs on a Raspberry Pi 5.

The lamp uses 24 V RobStride BLDC servo motors connected over CAN. The Raspberry Pi now handles motor control, lighting, and animation playback locally, so the lamp no longer needs to be continuously controlled by my main PC.

I still use a separate animation editor that I built for creating movements. Each joint has its own timeline with position keyframes, velocity, torque limits, and controller parameters. Finished animations are sent to the lamp and played back locally.

I’ve also installed an addressable LED ring with a 3D-printed diffuser inside the head. Brightness and transitions are now part of the same animation timeline, allowing the light to be synchronized with movement.

This video is a quick test of the new setup. I’m currently tuning the motor parameters, brightness curves, and transition timings before using the light in more expressive animations.

This is the first movement test with the assembled prototype. The motion is still rough and the wiring is currently a complete mess, but all the connected joints are finally moving — so naturally, I made it dance.

Next: smoother trajectories, control tuning, and proper cable management.

UPD: In this project I use robstride actuators, series 00 and edulite 05

Hi everyone!

I recently decided to dive into animatronics and started building an open-source robotic desk lamp inspired by expressive animated lamps from Pixar.

This is still a very early mechanical prototype. Right now only the base and the first joint move, and I'm designing the rest of the arm.

I'm looking for advice on one of the biggest design challenges: how would you route the cables through the moving joints while keeping them hidden and minimizing stress on them?

If you've built articulated robots or mechanisms before, I'd really appreciate any examples, photos, or resources.

I'd also love to hear your ideas for useful features. My current plan is to eventually add a depth camera so the lamp can understand its surroundings and interact with people. As a fun long-term challenge, I'd even like to see if I can teach it to jump or move around on its own.

Any suggestions or criticism are very welcome!

So here's the situation: my wife knits, I'm an engineer with an incurable "let me automate this" complex. Result: KAST, an ESP32-S3 knitting row counter with an LCD screen, battery, and three buttons. No subscription, no cloud, just click-click and knit.

The plan was beautiful: Spec → Implementation → Build → Flash → Debug → Verification, all through an AI agent (GPT-5.5 via OpenCode). I wrote a pile of docs, figured I'd sit back with a coffee and just approve pull requests while the AI built everything.

Reality: the AI is a genius at C, a disaster at geometry.

The moment we got to rendering the UI in LVGL — everything fell apart. The model started placing screen elements like a drunk interior designer: text overflowing the edges, the battery icon overlapping the row counter, buttons "hiding" behind the background. Every offset fix birthed a new bug in a neighboring widget — classic whack-a-mole, except the mole is an x/y coordinate.

Ninety straight minutes of debugging "why is the number 47 half invisible."

The fix was painfully boring: no magic, just brute-force formalization. I pinned down every single pixel in the spec — a literal "widget → x, y, w, h" table in a document. Once that formalization existed, the AI stopped "improvising" and started assembling the interface strictly by blueprint. Boring, but it worked.

The lesson: AI writes great code when you already know exactly what you want, down to the last pixel. The second you leave room for creative freedom, you get a modern art piece instead of a row counter.

After that came the real test: field trials on a live human (wife — a merciless QA engineer with zero NDA), feedback on battery life and UI responsiveness, and finally a stable working device.

TL;DR: AI doesn't replace the engineer — it forces you to write specs so detailed that you end up understanding your own project better than before. LVGL is its own special circle of hell that demands ruthless formalization, or the AI will decide layout design is a form of self-expression.

For those asking "how did you actually structure this":

Before writing any code I set up a few docs the agent reads on every task:

• TOOLS.md — build/flash/debug commands, board specs
• AGENTS.md — coding conventions + workflow rules
• PROJECT_SPEC.md / IMPLEMENTATION_PLAN.md / ACCEPTANCE_CRITERIA.md — what to build, in what order, and how to know it's actually done

Every new feature got its own mini-spec folder (features/001-.../FEATURE_SPEC.md, plan, acceptance criteria) so the agent never lost context mid-task. First milestone was a deliberate "stage zero": build → flash → boot → show firmware version on screen, just to validate the whole pipeline before touching real functionality.

All of it's in the repo if you want to steal the structure.

Question for the community: how do you all usually automate/wrangle embedded screen UI design (LVGL or otherwise)? Did you find a way to make an AI agent reliably handle layout, or did you end up hand-formalizing pixel positions too? Curious if there's a smarter approach than "spec every coordinate by hand" — feels like there should be a better middle ground between "let the AI freestyle" and "I become a human LVGL compiler."

Demo: https://www.youtube.com/shorts/3yuL7Apywl4
Repo: https://github.com/Nikolay-Tyulkin/KAST

Hi everyone!

A little update on my wearable knitting row counter project KAST.

A while ago I shared the first version here:
https://www.reddit.com/r/esp32/comments/1ug2dpb/i_made_a_wearable_knitting_row_counter_for_my/

The idea was simple: my wife was tracking knitting rows in a notebook, so I built her a small dedicated ESP32 device instead of using a phone app.

The first version worked, but thanks to your feedback I had a few things to improve.

One suggestion that I really liked was:

"Why not use a normal watch strap instead of making a custom one?"

So I redesigned the enclosure and made KAST v1.1.

Changes:

• ⌚ Added standard 22mm watch strap compatibility
  • silicone straps
  • leather straps
  • nylon straps
  • metal mesh straps
• 🔋 Improved battery life
  • brightness control
  • display sleep mode
  • power optimization
• 📡 Added a Wi-Fi settings page using ESP32 AP + captive portal
• 🖨 Redesigned the 3D printed enclosure
• 🧩 Improved ergonomics and everyday usability

Hardware:

• Waveshare ESP32-S3-LCD-1.69
• Li-Po battery
• ESP-IDF firmware
• LVGL interface
• 3 physical buttons
• Custom 3D printed enclosure

The original custom silicone strap was fun to make, but in real usage a standard 22mm strap turned out to be a much better solution. Now the device can be customized like a watch.

Open source:

GitHub:
https://github.com/Nikolay-Tyulkin/KAST

3D models:
https://www.thingiverse.com/thing:7380179

Thanks again for the feedback on the first version - especially the strap suggestion. It was one of those small comments that actually changed the final design quite a lot.

My sister and I have been working on a small open-source project built around an ESP32.

The idea was simple: instead of another tiny black ambient light sensor on the desk, why not turn it into something that actually looks like part of the workspace?

So we built LumaBloom.

The light sensor is hidden in the center of the flower and continuously measures ambient light, while the desktop application adjusts the brightness of all connected monitors over USB.

My sister wrote the firmware and desktop software, while I designed the hardware and the fully 3D printable enclosure.

Current features:
• ESP32-based
• USB connection
• Ambient light sensing
• Automatic brightness adjustment
• Supports multiple monitors
• Fully 3D printable enclosure
• Customizable petal and pot colors
• 100% open source

We're still adding new features and would love to hear ideas from the ESP32 community.

If you were building something like this:
- Which light sensor would you choose?
- Would you add wireless connectivity (Wi-Fi/BLE) or keep USB-only?
- Any features you'd like to see?

GitHub:
https://github.com/mkdsfm/LumaBloom

This is KAST, a small wearable device based on an ESP32-S3 board with a 1.69" LCD, physical buttons and battery power. In my case, the firmware works as a knitting row counter, but the enclosure can be reused for other small wearable electronics projects.

The full enclosure was designed in Fusion 360. The model includes a front case with a screen opening, back cover, button pushers, strap holder, strap fastener and the internal ESP32-S3 board placement.

I tried to make the device easy to assemble and modify. The enclosure is split into separate printable parts, so the design can be adapted for other boards, sensors or small wearable projects by changing the internal layout and firmware.

The strap is designed as a soft silicone part, not as a rigid printed part. I used Shore 40A silicone because I wanted the device to feel more like a wearable product rather than just a 3D-printed electronics box.

One of the most interesting parts was designing a mold for casting the silicone strap. The mold itself is intended to be 3D-printed and then used for silicone casting. It worked for this prototype, but I don’t think the mold design is very successful for repeated reuse yet, so I would really appreciate critique and ideas on how to improve it.

Although KAST is currently a knitting assistant, the same enclosure concept could be used for other wearable ESP32 projects: counters, timers, small remotes, BLE devices, sensor modules or custom handheld/wrist-mounted tools.

Thingiverse:
https://www.thingiverse.com/thing:7372245

GitHub with CAD files, firmware, BOM and assembly notes:
https://github.com/Nikolay-Tyulkin/KAST

I would appreciate feedback on the enclosure design, strap attachment, silicone casting approach and 3D-printable mold design.