What if you could just describe a piece of furniture and get everything you need to actually build it?

In this video, I put a commonly known side table design to the test. I open the web, type in a description of a side table, and it generates an editable 3D model, along with the engineering drawings and a full build plan: cut list, joinery, and step-by-step assembly. Then I take those files straight into the workshop and build the real thing from scratch.

Is it common practice to reduce the distance between the LED strips and the diffuser, as shown below?

As of time being the project is in its early phase of its planning. Let of details of final implementation need to be decided. All hardware purchases need to be made. Few further pictures (current state prior to placing LED-technology in fixture) in comments to this OP.

I want to carry out a radical retrofit—meaning I’ve removed everything associated with the T8 G13 fluorescent tube technology from the first of three fixtures—and replace it with LED strip technology. Several questions have arisen during the planning phase, but for now, I want to address the following point.

The fixture is nearly empty; only the rocker switch and the GST18 connectors remain (where power enters and is passed on to the next fixture in the chain). The simplest mounting method would be to stick the strip directly to the bottom of the fixture housing. However, the side of the fixture containing the switch would then block light from spreading toward the front edge of the kitchen countertop. This is because the transparent plastic housing—which acts as a diffuser—faces the wall beneath the overhead cabinet.
Hence my idea to reduce the distance between the LEDs and the plastic cover by using a U-profile, attached (via adhesive or another method) to the top inner surface of the fixture using one of the U-profile's side flanges (rather than its base). I’ll likely need to leave a small gap between the LEDs and the diffuser to allow for some heat circulation.

I have standard rivets and a riveting tool available. However, I haven't yet checked whether the thickness of the rivet assembly fits the project's constraints—the fixture needs to sit flush against the underside of the overhead cabinet to which it is mounted. Therefore, if I were to use adhesive to attach the U-profile to the fixture housing, the adhesive would need to effectively conduct heat to the fixture's metal casing.

Phone connects over Bluetooth, it grabs the album art, pulls the colors, and drives an LED matrix in real time — so the whole thing changes color with every song. Built it myself on a Raspberry Pi; still finishing a custom PCB and enclosure.

A few people have asked if they could get one, so I'm thinking about doing a small batch. Two honest questions:

Would you actually want one? (just gauging if it's worth doing)

What would you want it to do — any features, sizes, or options?

Not selling anything yet, just figuring out if this is real. If you want to be kept in the loop there's a form in my profile. Happy to answer anything about the build 🙂

Hello everyone, I have made this productivity tracker as a small project for myself, and I posting here to ask all of your suggestions.

Context:

I wanted to get the same level of satisfaction that I get after speding somee X amount of hours in a task, this was mainly inspired by steam's playtime, for the people who do gaming, I am sure you're satisfied or feel a sense of pride in your "investments" in a game. For context I have like 500 hours all games combined in my library :)

The reason of this post is to ask all of ur suggestions on how to improve this further, apart from idle animations, smooth screen transitions which I plan to make soon, share your vision of this so I can improve this further and post it in github for those who are interested in building a similar device.

I know that the seconds are being counted in the screen that is intentional for the testing purpouses.

I have used no chatgpt or any AI of any sorts and this is my first "real project" built from scrach and I have only taken help from the documentation of the code libraries of adafruit GFX and some pin out diagrams of the OLED. The base logic and UI remains 100% coded by me.

Thank you for giving your attention to this post and have a wonderful day :)

My github profile is given below, I will soon add the code and the schematics.

Github profile (code coming soon): https://github.com/Cashew1108

​Decided to document my workflow putting together this mini-project from scratch.

​The video walks through the whole process: looking up the best project setups, calculating measurements on a water bottle, and then the fun part, wiring up the breadboard with an HC-SR04 ultrasonic sensor, a micro servo, some LEDs, a buzzer and lastly an LCD screen.

​Everything is up, running, and successfully printing real-time distance values to the display!

​I’m thinking about where to take this build next. What are some cool ideas or features you think I should expand this into?

I’m building SnapShop AI to help with that. You can take a picture of an item, part, tool, fitting, etc., and the app tries to identify it and show buying options — local, online, and wholesale/import options when available.

It’s built for DIY projects, homeowners, contractors, and anyone who has ever wasted time searching the wrong words or making extra trips to the store.

I’d really appreciate honest feedback:

Did it identify the item correctly?

Were the results useful?

Was anything confusing?

What would make you keep or delete it?

iPhone: https://apps.apple.com/us/app/snapshop-ai-visual-shopping/id6757250945

Android: https://play.google.com/store/apps/details?id=com.kolio90034.snapshopai

Not looking for praise — I need real feedback.

After the great feedback on our previous post, here's a short video of the system in action.

The departure board is fully controlled by Arduino and synchronized with real-time audio announcements. As each train departure appears on the display, the corresponding station announcement is played automatically.

It started as a small side project, but it quickly became one of the most appreciated features of our LEGO railway diorama. At Maker Faire Trieste, many visitors stopped just to watch the departures and listen to the announcements.

The announcements are in Italian and the subtitles are also in Italian, but we think the synchronization between the display and the audio is easy to understand even if you don't speak the language. 😊

We're quite happy with how much realism this little detail adds to the station atmosphere. 🚆❤️

I built this because I wanted a dashboard for my homelab that actually looked like ink on paper, not just another glowing screen. It runs on a Pi Zero. But because I absolutely refuse to SSH into a headless Pi every time something breaks, things got a little out of hand. I ended up writing a custom Wi-Fi recovery portal and a CI pipeline to build ready-to-flash images. The repo is open-source if anyone wants to steal the code.

Here is the breakdown of the build and why I over-engineered the hell out of it.

The Hardware

• Brain: Raspberry Pi Zero W (small enough to hide).
• Screen: Waveshare 2.9" Tri-colour (Black/White/Red) e-paper module.
• Sensor: AHT20 (I2C temp/humidity sensor).
• Wiring: I skipped the plug-and-play HATs because they cover all the GPIO pins. I wired it bare-metal—SPI for the screen, I2C for the sensor—so they could share the board and fit inside a custom case without colliding.

The Over-Engineering (Fixing the annoyances of IoT)

I hate dealing with headless smart devices when things break, so I spent most of my time fixing the classic Raspberry Pi friction points:

1. The "Changed My Router Password" Problem Usually, if a headless Pi can't find the Wi-Fi, it just dies silently, and you have to plug in a keyboard or re-flash the SD card.

• My fix: On boot, InkNode tests the connection. If the internet is down, it halts the boot, spins up its own temporary Wi-Fi Access Point, and physically draws a QR code on the e-paper screen. You scan it with your phone, hit a local web portal, type in your new Wi-Fi credentials, and it safe-boots.

2. The "Spaghetti Code" Problem: E-paper is incredibly slow to refresh. If your code waits for a weather API to respond before updating the screen, your device freezes.

• My fix: Total decoupling. A background thread handles the network polling and fires lightweight plaintext telemetry directly to my MQTT broker (for Home Assistant). A separate Python Hardware Abstraction Layer (HAL) handles the screen, pulling the latest state from memory so the UI never blocks.

3. The "List of Terminal Commands" Problem I didn't want to run sudo raspi-config and pip install Every time I messed up my SD card.

• My fix: I built a CI/CD pipeline using GitHub Actions. Whenever I push a release, it grabs the canonical Pi OS Lite image, injects my Python code and cloud-init scripts into the filesystem, shrinks the image size, and spits out a ready-to-flash .img file. You literally just flash it, plug it in, and it works.

Happy to answer any questions about the hardware, the e-paper limitations, or the GitHub Actions pipeline!

Follow-up to the v2 trajectory post and the noise characterization experiment. v3 adds image-based visual servoing.

The problem with v1

v1 tracked horizontally by steering the car body. Ackermann steering has a minimum turning radius — if the tag moves outside a cone in front of the car, the only recovery is a multi-point turn. The camera was locked forward and the car had to point at what it wanted to see.

IBVS decouples the camera from the chassis. The pan/tilt gimbal tracks the tag in pixel space regardless of where the car is pointing, and the car centering logic works from the gimbal's pan angle rather than raw image error. The camera can follow a target that the car physically can't yet reach.

What v3 adds

IBVS core — pan and tilt are driven by pixel error feedback: eu = tag_x − cx, ev = tag_y − cy. Error is smoothed with an EWMA (alpha=0.8), a 10px deadband prevents hunting at center, and corrections are capped at 2° per frame. The result is a gimbal that follows the tag continuously rather than only when the car is pointed at it.

Four operational modes — ibvs_test (gimbal only, no drive), manual_ibvs (gimbal + WASD), rat_chase (gimbal + autonomous centering + forward drive), and world_ibvs (full v2 dual-tag world frame behavior). The modes let each layer be validated in isolation before combining them.

rat_chase — the autonomous mode shown in the video. Car centering derives a steering angle from the gimbal's current pan angle via a feed-forward gain, then drives forward at a configurable speed and stops at a distance threshold. The car is on a test rig in this clip so the wheels are suspended — this is a hardware-in-the-loop simulation of the drive logic before putting it on the floor.

ibvs_anchor_mode world frame — tag0 alone is now enough to anchor the world frame. First detection seeds T_world_anchor; every subsequent frame derives world → car_base from that anchor and the current tag0 pose. No second tag required. The full URDF renders in RViz2 and the car trajectory publishes live.

Trajectory visualizer — trajviz.py reads the PLY files output by tf_bridge and produces an interactive Plotly HTML with a color gradient over time, cubic spline overlay, and sliders for spline order and smoothing weight.

What the video shows

The car is suspended on a test rig — wheels off the floor — running in rat_chase mode. Pan/tilt hunts briefly at the start while the EWMA settles, then locks onto the tag and tracks it. The gimbal motion looks smooth on the car itself; some snappiness is visible in the camera output feed, which is the per-frame correction still present at the edges of the lazy band. Drive and steering commands are being issued but the wheels aren't in contact with anything.

Next step is putting it on the floor and running it for real.

Bugs worth mentioning

TF never broadcast in ibvs_test/manual_ibvs. tf_pub.on_frame() was only called inside _do_chasing(), which the ibvs_test and manual_ibvs branches never reach — they return early. Pi was detecting the tag correctly but zero messages reached tf_bridge. Fix: added the on_frame() call directly in the early-return branch.

Z filter rejecting all valid frames — twice. The first version checked car_base_pos[2] against a floor threshold; car base is at Z≈0 so every frame failed. Fixed to check camera height instead. Second version: valid camera height readings clustered just below the threshold (0.000–0.054m vs 0.055m cutoff) and still got rejected universally. Root cause was that I was physically lifting the car during testing so Z filtering is inappropriate in that context. Made the filter an opt-in ROS2 param, defaulted off.

Velocity gate blocking hand-carried movement. The jump gate inherited from v2 was set at 10cm — fine for autonomous driving, but every footstep when carrying the car exceeds that. Result: 62 skipped frames in 11 seconds, 2 trajectory points recorded. Added a separate ibvs_max_jump_m param (default 1.0m) for the ibvs_anchor path.

What's next

Put rat_chase on the floor with the wheels down. The steering and drive logic is implemented and confirmed sending commands — it just hasn't chased anything yet under its own power in v3. That's the next session.

References

Post history

• v2 noise characterization experiment
• v2 trajectory post
• v1 tag chaser
• PiCar-X introduction

Hardware / code

• PiCar-X on Amazon
• Git repo

I made this over the last few months. It’s an automated Magic the Gathering card scanner and sorter. For now it’s just a working prototype, but eventually it may stand on its own. What do y’all think?

https://youtu.be/9JX8J1ihZH4