I just finish putting up our Autonomous Lamp. A 3D-printed desk arm that moves and talks. Runs on Autonomous OS we built for robots. We open source everything and here's the short version.

Our Autonomous Lamp

The arm

5 degrees of freedom. Five STS3215 bus servos, daisy-chained on one TTL bus, into the board through a USB adapter. One cable for the whole arm. No driver board.

First job: servo IDs. New STS3215s ship as ID 1, so I gave each a unique ID one at a time, then calibrated homing. Homing lives in the servo EEPROM, so it survives a reflash. Do it with the arm open.

Power

Single 12 V / 5 A adaptor, ~42 W sustained. A buck steps to 5 V for the board and LED ring. Amp runs on 12 V directly. Board draws ~1.8 A, spikes to 2.5 A at boot. Ring gets capped near 1 A, full white 64 LEDs would pull 3.84 A and brown out the buck. All grounds star-point at the buck output on their own wires.

Sound

Moving audio off the onboard codec killed most of the noise. A USB DAC feeds the amp through a short twisted lead, run away from the 12 V harness. The onboard codec stays wired for the sensing mic only.

Two honest gotchas: the sensing mic is the MEMS mic on the OrangePi board, so it has to be desoldered and re-mounted in the base, fiddly, but skip it and you lose ambient sensing. And the buck I used still adds a faint hiss of its own, it's on the list to swap out.

Software

Cleanest part. Flash Linux, run the installer, ~15 minutes to Autonomous OS. The robot declares its hardware in the ROBOT.md in our repo and the OS mounts only that. Behaviors are markdown skills. Type what you want in the app, it writes the skill, live on the next conversation.

The 1st prototype

The final design

What's inside the Lamp

3D printed parts

We host AI models locally but never liked those cold industrial server racks. So we designed our own chassis, something we'd actually want sitting in the middle of the office.

It's CNC'd from an 5mm solid aluminum plate, milled inside and out. The triangular cutout pattern does double duty: it keeps the frame stiff without the weight, and the triangles map to the airflow path for the four GPUs, which stand vertically. 18 fans on one controller keep it cool at full load.

Each of the 4 GPUs reaches the board over its own PCIe 5.0 riser, custom-cut and sleeved to fit the chassis exactly.

Four cards pull close to 3,000W, so it runs two 2,000W supplies with native 12V-2x6 into one distribution board, off the rear, for headroom.

Underneath is an ASUS W790E-SAGE SE with a Xeon w5-3423 and 192GB of ECC. The whole thing is 15.5 inches square and about 66lb, anodized silver.

Design files are open source if anyone wants to build one, link in comments

https://preview.redd.it/6i2lsgl97bjh1.jpg?width=1672&format=pjpg&auto=webp&s=d27e07bbae1d7200d30930ee6accd5b9a2378d61

https://preview.redd.it/ju8tdrmb7bjh1.jpg?width=2560&format=pjpg&auto=webp&s=7714e7deeb3c553caec56af005cc5ed484ec12f9

https://preview.redd.it/jsye88qk8bjh1.jpg?width=1700&format=pjpg&auto=webp&s=a2623e8aa9f87bb41227a1897062b3a57c8a10f5

https://preview.redd.it/d592v87jabjh1.jpg?width=2560&format=pjpg&auto=webp&s=c95de9fce9aa6aa3a4305e5369f2e191cc18b5b5

A thank you to people who build local-AI tools in their spare time. You put in the work, we want to send something back.

Drop your local-AI / self-host / agent / GPU-tooling repo below.
My team picks one they find interesting. No star requirement, no follow, no catch.

Winner gets a Autonomous Computer 2-GPU chassis, $999 in value, shipped free globally.

What is it? The chassis is designed by us:

1. CNC in house from solid billet aluminum,
2. Cut to fit 2x RTX 4090/RTX 5090/RTX Pro 6000 Blackwell,
3. Including 2x PCIe 5.0 risers (full x16 each),
4. Six fan-slots mapped to the airflow path.

We run one in the office every day.

Honest bit: you win the chassis plus the risers (the part you can't buy standalone). You bring the mobo, PSU, cooling, GPUs, storage, RAM build-your-own, not turnkey.

Rules: drop your repo, say a line about what it does, we pick one. No catch, shipped free.

Design to be shown in the office

https://preview.redd.it/10xsoel8oxhh1.jpg?width=836&format=pjpg&auto=webp&s=258dd4ea8a4cafedea071306232e5ec4c37d4cae

https://preview.redd.it/0zhpfdl8oxhh1.jpg?width=836&format=pjpg&auto=webp&s=7535f643cb2d7e0d84732079978cceecef9872f6

https://preview.redd.it/4fqvqdl8oxhh1.jpg?width=1672&format=pjpg&auto=webp&s=bd6d42eb159fe29db243e109db85f6f582d6d758

Been building these multi-GPU rigs for a while, and this one's the config I'm happiest with, so figured I'd share the details here.

The frame is our own design, CNC'd aluminum, tower layout: motherboard vertical in the middle, both cards mounted upright on PCIe 5.0 x16 risers, PSU hanging off the back, and a fan tray up top pulling air straight through the card stack.

The whole thing closes up with a laser-cut triangle-lattice shell. Footprint ends up around 12.5" square enough to sit comfortably on a file cabinet. It's also quite heavy, will need a second pair of hands if you want to move it around.

Specs (the unit the benchmarks ran on):

• 2x RTX Pro 6000 Blackwell (96GB each, 192GB total)
• CPU: AMD EPYC 9124 (16C/32T, single NUMA)
• RAM: 377GB
• Storage: 915GB NVMe
• PCIe 5.0 x16 to each card, no switch, no NVLink
• Serving: vLLM, TP=2

The two cards talk over PCIe P2P, which the Pro line actually supports, and we run tensor parallel (TP=2) in vLLM.

What it serves: DeepSeek V4-Flash 0731, the 284B MoE, native FP4, fully in VRAM. Pulled the network cable to check, it keeps running, which never stops being satisfying.

Numbers from our benchmark sweep (vLLM, per-stream generation):

• 1 user: 209-286 tok/s depending on content type
• 4 users: 138 tok/s each
• 8 users: 111 tok/s each
• 16 users: 75 tok/s each
• 24 users: 57 tok/s each, ~1,000 tok/s aggregate, TTFT still ~0.5s

Saturation knee is around 32 concurrent. So this box comfortably covers my whole team, with everyone still getting faster-than-reading speed.

Thermals: 815W for both cards under sustained load, 76C peak, no throttling with the top fan tray doing intake-through-stack. Noise-wise it's no laptop, but it's fine to work next to.

Lives on the cabinet next to my desk, within arm's reach. If it were loud, I'd be the first to suffer.

Happy to answer anything about the riser setup, the airflow layout, or the benchmark config. And curious what everyone else is serving on dual-card boxes, feels like 192GB is a real sweet spot right now

First, thanks to everyone who joined last week's post. Lots of impressive repos, but we only had one product to give.

So, as promised, we're making this a weekly thing.

You can re-enter with the same repo as last week, because like I said, there were so many good ones that missed the prize.

The rules stay the same:

1. Drop your repo and say a bit about it.
2. My team takes a look. If we like it, the prize is yours.
3. No star requirement, no follow, no catch.
4. The product ships to the winner for free.

You do the work for the community, and we want to say thanks.

This week's prize: Autonomous Harness (it was Fleet but beta users told us the name didn't land, so we renamed it).

What is this Harness device? If you run Claude Code on a laptop, Codex on a desktop, and a few more agents on servers, some at home, some at the office. It gets hard to manage them all. Harness lets you talk to every agent across every machine, dispatch tasks by voice, and approve or reject with a knob instead of juggling ten terminal tabs. It works with Claude Code, Codex, Cursor, etc...

Last week's winner: vdo.ninja, WebRTC video feeds into OBS, used by streamers worldwide.

Drop your repo below. Thanks for what you build.

Deadline: Sunday Aug 2nd. Winner announced on the next Tuesday.

I might not be able to reply to you all but be assure that my team will check all of the repos here.

A thank you for open source builders. You put in the work, we want to send something back.

Drop your open source repo below. My team picks one they find interesting. No star requirement, no follow, no catch. Winner gets a Fleet device shipped for free.

What's Fleet? I was running Claude Code on my laptop, Codex on my desktop, more agents on servers. No way to manage them all. So I built a device that sits on your desk and connects to every agent across every machine. You talk to it, agents send you status updates, you don't need 10 terminal tabs.

Been using the prototype for a month. Cant live without it.

Drop your repo. Thanks for what you build.

Edit: I didn't think that I can gather this many great people. I might not be able to reply to you all but be assure that my team will check all of the repos here. Will try to make this a weekly event, so for this week, the deadline is Sunday. Big thanks to all of you.

I had three machines running different models and every single day I was SSH-ing between them just to figure out which port was serving what. Ollama here, vLLM there, ComfyUI on some random port I'd forget by tomorrow. It sucked

So I wrote Grid. Basically it sits on top of all those machines and gives you one URL that routes requests to whichever one has the model you asked for. You don't need to remember IPs or ports anymore. Point any OpenAI-compatible client at it and it just works

It's got a built-in llama.cpp engine too so you can skip Ollama entirely. And recently, I added the ability to join ChatGPT subscriptions as an engine in the grid. Your local Qwen and GPT-5 sharing one endpoint. Pretty wild

There's also a desktop app available if you're not into using terminals. It offers the same functionality but is more friendly for non dev users

Using it daily but this is still in early stage. All feedback and contributions are appreciated

I kept seeing hex honeycomb used for pretty much everything so I ran some test coupons in both, same wall thickness and cell size, and just poked at them by hand and put some weight on them.

The first thing I noticed was how little the triangle ones moved. I honestly didn’t expect it but it kinda makes sense once you think about it, a triangle can only be one shape if the sides are fixed, it can't fold sideways the way a square can. So bending and twisting them did almost nothing. Downside was they were heavier and took longer, more struts packed in for the same area.

The hex ones also used less plastic for similar coverage, which is one of the reasons honeycomb shows up so often. Pushing straight down on them, the walls kind of squished and sprang back instead of cracking. Though I want to caveat that, I was printing in PETG. I tried one in thin-wall PLA and it just snapped, so the springy thing is probably a material and wall thickness thing more than the pattern.

I also printed a curved part, a wrist rest with a domed top, and the triangle lattice held up well there. That tracks with how curved shells usually get stiffened, geodesic domes are all triangles, and a flat hex sheet doesn't really want to wrap a dome without distorting the cells. So on curved geometry the triangle edge carried over, it didn't just disappear once the surface wasn't flat.

Quick way I think about it: pick the pattern by what the part needs to do. Triangles when you don't want the part moving under bending or twist, hex when you want it lighter or a bit of give and some airflow through the cells. Lots of parts probably want both in different spots.

One thing that bit me early: if the pattern walls get thinner than about 2x nozzle width (~0.8mm on my 0.4) the fine cells under-extrude and the coupons come out inconsistent, so watch that if you're comparing.

Anyone tried these on curved parts? Curious if the triangle edge holds up there or if it flips.

Every day after work I just cmd+ctrl+Q to lock the screen and leave. MacBook stays plugged in, everything keeps running in the background. But the problem is when I'm home and want a file from the office machine, I'm too lazy to turn on my home laptop just to remote desktop. When I'm cooking, chilling on the couch, or out somewhere, pulling out my phone and messaging to get the file is way more convenient

Normally people think of 2 ways:

Remote Desktop, you still gotta turn on your home computer, sit down, open the app. What if you're driving? What if you're out? Don't tell me you'd pull over and grab your laptop. The question isn't "can you do it", it's "is it convenient?" Answer is no.

Cloud Storage (iCloud in my case), sync files up then download. But you have to remember to push the file up first. Half the time I forget and well, sucks to be me. Plus the free tiers give you barely any space, backing up iPhone photos/apps data sometimes doesn't even fit, let alone a whole project workspace.

And u guys IOS users know how the sync works. Besides client docs and contracts, there's personal photos and stuff too. I'm not pushing all that to someone else's cloud. Less data leaving my machine the better.

Then I found a simpler way that ties into my current setup using Grid + Hermes. Since installing it I haven't touched Ollama or vLLM apps anymore

GRID works pretty simply: it sits between your apps (Openclaw, Hermes, Cursor...) and whatever AI engines you're running (Ollama, vLLM, ComfyUI...). Instead of each engine sitting at its own IP/Port, Grid puts them all behind one endpoint on a cloud relay. Your app just points to that one link and can call any model, from anywhere. If you want it private you can set it to Private and invite people one by one. Works great for office sharing too

A few real situations I face daily:

Client says "change pricing from $500 to $450" plus some other requests. I forward the message to Hermes: "find the line with $500 and change to $450 and add the other requests to the file". Hermes edits the file directly on the MacBook disk at the office. Done. I never touch the office machine

There's this dev at my company who set up Hermes to run code with ClaudeCode. The agent pastes prompts into ClaudeCode and runs it. He said prompting through Telegram has process limits and agents don't get the full picture like you would with an IDE. Basically he recommends setting it up that way for full context + tooling. He even installed via CLI but the terminal had too many words for me

This setup is super handy if you freelance. Imagine lying in a hammock on your balcony or at a beachside cafe, client messages something urgent, pull out your phone, msg Telegram, done.

What this setup can do:
- Access files/workspace from anywhere via Telegram
- Data stays local, nothing leaks out if you run your own grid
- Hermes has persistent memory, remembers projects across sessions
- Cost basically zero
- If you don't have beefy hardware to host models, you can use models others are hosting.
- Join Grid + Lock your machine after work, your apps keep running smoothly. u can call it from home or let others call it, kinda like renting it out

Cons:
- Depends on office network, power outage or machine crash = no connection
- Speed isn't as fast as cloud APIs
- Weak office WiFi means higher latency
- MacBook uses ~RAM for the model, opening heavy apps at the same time might lag
- If your Mac is old you can only grab models to use like an API, can't host your own

Honestly the coolest part of Grid is you come home from work and instead of your laptop just sitting there waiting for tomorrow, it becomes a gateway + agent machine. Pretty convenient and fun ngl.

Hi everyone,

My team and I have been working on a project called Autonomous Soul, and I'd love to get some feedback outside our own product bubble.

The core idea is simple: Instead of keeping an AI companion trapped inside another generic mobile app, we wanted to give it a physical body. So, we built handcrafted papercraft characters with a passive NFC tag hidden inside their structure. When you tap the figure with your phone, that specific AI companion wakes up exactly where you left off.

We arrived at this concept by looking at three major limitations in how humans interact with toys and software today:

• The Tamagotchi Dilemma: Virtual pets create emotional attachment, but their two-way interactions still feel severely limited by rigid hardware.
• The Dumb Art Toy Problem: Premium designer toys look amazing on a desk, but they're completely static. The interaction ends after unboxing. Or something like the amiibos of Nintendo, solely for their games and can not interact with you.
• The Ghost-in-the-Shell Chatbot: AI companion apps can hold incredible, deep conversations, but they feel hollow because they only exist as pixels on a screen. There is no physical anchor.

We wondered what would happen if those three ideas became a single product.

Every Soul figure contains a passive NFC tag. We don't use the tag to store conversations or heavy AI models. Instead, every tag uses its factory-programmed unique ID (UID) as the permanent, immutable identity of that character. That identity is cloud-linked to:

• Its own specific personality matrix (Prompt weights)
• Its long-term contextual memories (Vector DB)
• Its ongoing relationship history with the owner

Once a figure is paired, it belongs strictly to one user account, almost like adopting a real pet instead of just logging into another chatbot.

The UX Trade-off We're Debating:

One major design decision we've debated internally is how we handle user sessions: You cannot simply open the app and start chatting, and the app won't stay unlocked forever.

To talk to that character, you have to physically tap the figure first. This tap opens a 1-hour interaction window. Once that hour is up, the session automatically locks, and if you want to continue the conversation, you have to physically tap the papercraft figure again to refresh the connection.

We know this is objectively less convenient than opening a standard app shortcut or leaving a chat window open indefinitely. But we are intentionally trading convenience for physical friction and ritual.

That 1-hour constraint forces a deliberate boundary. It makes the companion feel less like a piece of disposable software running in the background, and more like a physical entity that you choose to spend intentional time with. It changes the dynamic from "always-on utility" to a focused, real-world visit.

I'm genuinely curious to get the perspective of this sub: Would you actually prefer an AI companion that requires a physical object to interact with, or is this just adding unnecessary friction to a software solution?

Hi team,

We all know the benefits of NFC: secure, low-latency, zero-power data transmission. But instead of deploying it for standard access control or payment pipelines, my team and I are building a project called Soul with the goal of combining the new tech with an old hobby. We are using NFC as the physical "DNA" to anchor decentralized AI Agents into handcrafted papercraft figures.

If you look at how humans interact with toys and software today, there are three major limitations that we’ve hit:

1. The Tamagotchi Dilemma: Virtual pets create great emotional attachment, but their two-way interaction is severely bottlenecked by 90s-era 8-bit logic hardware.
2. The Dumb Art Toy Problem: Premium action figures and designer art toys have incredible collectability and physical presence on your desk, but they are completely static. The interaction ends the moment you unbox them.
3. The Ghost-in-the-Shell Chatbot: AI companion apps are getting really interesting recently. Some chatbots have deep, multi-layered intelligence, but they feel hollow because they only exist as pixels on a screen. There is no physical anchor.

Each Soul would come with an passive NFC tag as the connective tissue that bridges all three worlds.

[Handcrafted Papercraft] —--->(Passive NFC Link)---------—-----> [Multi-Layered AI Agent]
(Physical Collectible)   (manufacturer-assigned UID )          (Dynamic Persona & Memory)

We don’t use the tag to store heavy asset files. Instead, we treat the chip’s factory-hardcoded 7-byte UID as a unique genetic seed and a strict hardware validator:

• Strict 1:1 Character-to-Account Mapping: To prevent spoofing and maintain the exclusivity of the relationship, a Soul's physical UID can only be paired with one single user account. Once Account A completes the pair and claims ownership of that specific figure, the UID is permanently bound to that account in our backend. If Account B attempts to scan the same figure, the system rejects the pairing request.
• Cloud-Synced Long-Term Memory: While the hardware anchor is physical, the AI’s memory stack is cloud-synchronized under that specific paired account. This architecture allows seamless multi-device session continuity. A user can tap the papercraft figure with their smartphone at the office, switch to their tablet or a second device at home, and execute the tap again—the AI Agent will instantly pull the exact same context vector database and conversation logs. The character retains 100% of its memory across 4-5 different hardware devices, as long as they share the same master account.
• The Persona Generation Matrix: The validated UID acts as a pointer to a highly customized system prompt. No two figures—even from the same animal batch—possess the same persona. One might be highly analytical and quiet, while another is erratic and deeply philosophical.

We intentionally locked the digital companion interface behind the physical NFC handshake. You cannot simply open the app and bypass the physical figure. To chat with that specific personality, you must execute a physical tap on your desk.

By utilizing the under 4cm read-range constraint of NFC, we force a deliberate physical action. The papercraft body gives the AI a tactile shell, and the immutable NFC UID gives it a permanent digital soul.

We are currently optimizing antenna alignment within complex geometric papercraft cardstock folds to ensure the consistent read performance.

Would love to hear your thoughts from a system design standpoint, especially regarding our data mapping architecture or embedding NFC tags into non-traditional mediums like papercraft!

Building an open-source robot initially feels a lot like assembling IKEA furniture.

You start with a Bill of Materials (BOM) (a parts list detailing motors, bearings, screws, wires, batteries, sensors, and 3D-printed or CNC-machined components) and follow digital blueprints rather than a paper instruction booklet.

But the similarity ends the moment you flip the power switch.

A bookshelf is a static object designed to remain exactly as assembled. A robot, however, is a dynamic system that continuously executes a loop of sensing, computing, moving, and self-correcting. It must interact with a messy physical world while maintaining an internal estimate of its own state and surroundings.

For beginners, the easiest way to understand robotics hardware is to break it into three interacting pillars: Body → Sensors → Movement

1. Body: Physical Limits and Structural Stiffness

The robot's body — its chassis, brackets, plates, and rigid links — is far more than passive packaging. It is a fundamental part of the overall system.

If the frame flexes under load or vibrates excessively, the robot's internal mathematical model no longer matches physical reality. The software may assume a camera is pointing straight ahead while the actual hardware has shifted several degrees off-axis.

Degrees of Freedom (DOF)

A robot builds its physical capabilities one actuator or wheel at a time.

A rigid body moving freely in space possesses 6 Degrees of Freedom (DOF):

• Translation along X
• Translation along Y
• Translation along Z
• Rotation around X (Roll)
• Rotation around Y (Pitch)
• Rotation around Z (Yaw)

6 Degrees of Freedom

Robotic arms typically increase dexterity by adding joints that contribute additional controllable DOF.

Mobile robots operating on flat floors are often modeled with only 3 primary DOF: X position, Y position, and Yaw (heading).

Every additional actuator increases capability, but also adds weight, cost, power consumption, and control complexity.

CAD and Manufacturing Files

Before a robot exists physically, it exists inside CAD software. Two file formats dominate most robotics workflows:

STEP Files store precise solid geometry using mathematical boundary representations (B-Rep). They are the preferred format for engineering modifications, CNC machining, manufacturing workflows, and cross-platform CAD exchange. If someone wants to make engineering modifications, the STEP file is usually required.

STL Files discard design history and represent only the outer surface as a triangle mesh. They are most commonly used for 3D printing, mesh processing, and visualization. STL files are excellent for additive manufacturing workflows but poor for editing designs later.

Material Tradeoffs

Every material introduces different engineering compromises.

PLA is cheap and easy to print — excellent for rapid prototyping. However, it becomes soft at relatively low temperatures (~60°C) and can be brittle under mechanical loads.

PLA: Cheap and easy to print

ABS, PETG, and Nylon provide significantly better durability and impact resistance. Nylon is especially useful for gears and high-wear components, although it is highly hygroscopic and requires careful drying before printing.

Aluminum remains one of the most popular engineering materials because it offers an excellent balance of stiffness, weight, cost, and manufacturability.

Carbon Fiber Composites offer exceptional stiffness-to-weight ratios but come with significantly higher manufacturing complexity and cost.

2. Sensors: The Foundation of State Estimation

Sensors convert physical phenomena into numerical data. Together they form the robot's state estimation, its best mathematical estimate of its own position, motion, and surroundings.

Sensors are generally divided into two categories.

https://preview.redd.it/eszq9mu6p79h1.png?width=1828&format=png&auto=webp&s=1b6ac2346969df305f5f68f62b7ddf545935762a

Proprioceptive Sensors (Inward-Looking)

These monitor the robot's internal state.

Wheel Encoders measure wheel rotation and are used for odometry, velocity estimation, and distance traveled.

IMUs (Inertial Measurement Units) combine accelerometers and gyroscopes to measure linear acceleration and angular velocity. When combined with sensor-fusion algorithms such as Extended Kalman Filters (EKF) or Madgwick filters, they help estimate orientation, particularly pitch and roll.

One important caveat: yaw (heading) estimation from an IMU alone drifts over time because the gyroscope integrates angular velocity, and small errors accumulate quickly. This is why real systems always fuse IMU data with wheel odometry or an external reference (LiDAR, camera) to correct heading drift.

Internal Telemetry (motor current, temperature, battery voltage) helps detect hardware faults before they become failures.

Exteroceptive Sensors (Outward-Looking)

These observe the external environment.

Cameras convert light into RGB images used for object detection, scene understanding, and visual navigation.

LiDAR (Light Detection and Ranging) measures distance using laser pulses, producing a highly accurate geometric representation of the environment. Commonly used for localization, mapping, and obstacle avoidance.

Depth Cameras estimate the distance to objects across an image, allowing robots to generate dense 3D representations of their surroundings and perceive obstacles at different heights.

Calibration: The Hidden Software Layer

Raw sensor data is meaningless without spatial context. The robot must know exactly where each sensor is mounted relative to its body.

Intrinsic calibration corrects internal camera properties such as lens distortion and focal length errors.

Extrinsic calibration computes the transformation between coordinate frames. For example, camera_link → base_link or laser_link → base_link. In ROS, these relationships form the TF (Transform) tree.

Without accurate calibration, a robot may navigate with complete confidence toward the wrong location.

3. Movement: Turning Electricity Into Motion

Movement is the process of converting:

Electrical Energy → Torque → Motion → Controlled Position

Because the physical world is unpredictable, robots rely heavily on closed-loop feedback.

Actuators and Closed-Loop Control

A bare DC motor simply spins when voltage is applied. A robotic actuator adds intelligence by combining a motor, gearbox, encoder, and controller electronics into a single package.

Instead of commanding raw voltage, higher-level software typically commands position, velocity, or torque. The actuator's internal controller continuously compares the target value against sensor feedback and corrects any error.

The PID Control Loop

The most common feedback controller in robotics is the PID controller. It continuously evaluates:

e(t) = target − measurement

Proportional (P): Applies corrective force proportional to the current error. Larger error → stronger correction.

Integral (I): Accumulates past errors over time. This helps eliminate steady-state offsets caused by factors such as friction or gravity.

Derivative (D): Responds to the rate of change of the error. Acts as a damping force that reduces overshoot and oscillation.

Real-World Reliability: Stable Device Paths

Not every robotics problem is mechanical.

When multiple USB devices are connected to a Linux system, device names like /dev/ttyUSB0 and /dev/ttyUSB1 can change between reboots. A LiDAR assigned to /dev/ttyUSB0 today may appear as /dev/ttyUSB1 after the next power cycle.

For reliable deployments, developers create udev rules that map devices to stable names:

/dev/rplidar

/dev/kobuki

This prevents software from breaking due to changing USB assignments, a simple fix that saves hours of debugging.

Example Hardware Teardown: A ROS 2 Mobile Robot

To see how these three pillars come together, consider a typical ROS 2 mobile robot designed for navigation and SLAM.

           [Workstation / Remote PC]
                         |
                    (Wi-Fi Link)
                         |
                         v
[RPLidar C1] -----> [Raspberry Pi 5] <----- [Depth Camera]
(2D laser scan)   (8GB + Active Cooler)    (3D point cloud)
                         ^
                         |
              USB Data + dedicated 12V power
                         |
                         v
                   [Kobuki Base]
              (Differential drive + Batteries)

A Simple Mobile Robot With LiDar and 3D Camera

Body: The chassis uses multiple CNC-cut plates connected by threaded standoffs. A Raspberry Pi 5 acts as the onboard computer. For traditional robotics workloads, Nav2, SLAM Toolbox, Sensor I/O, a Pi 5 often provides sufficient compute without requiring a dedicated AI accelerator.

Sensors: Internal sensing comes from the Kobuki's built-in wheel encoders, gyroscope, bumper sensors (contact detection), and cliff sensors (drop/ledge detection, prevents the robot from driving off a table or stair edge). External sensing comes from the RPLidar C1 for 2D laser geometry and a depth camera for 3D perception.

Movement and Power: Locomotion is provided by the Kobuki differential-drive base. Velocity commands are sent through the ROS /cmd_vel topic. To avoid voltage drops and USB instability under load, the Raspberry Pi is powered through a dedicated 12V power line from the Kobuki base (converted to 5V via a regulator), not through a standard USB data port.

Modern robotics sits at the intersection of software and physical hardware.

A robot only performs as well as the weakest link in its stack. A rigid chassis, properly calibrated sensors, and reliable closed-loop actuators matter just as much as any SLAM algorithm, neural network, or AI model running on top of them.

Understanding these hardware fundamentals will save far more time in the workshop than chasing software bugs that are actually caused by physics.

A few days ago, I shared our 8x 4090Ds rig setup. It’s a beast, but let’s be real, not every office has the electrical infrastructure, the specialized cooling, or the massive budget to build and maintain a local supercomputer.  

So we also looked the other way: horizontal. 3 used Mac Studios on my desk + every junk laptop we could find in the office. Fully local AI fleet, no cloud, no data leaves the building. Here's the build:

3 Studio M2 Ultra, 192GB / 2TB each. 100+ "free-range" office laptops. Qwen on each Studio, a LAN router + ComfyUI for img gen.

Don't see many cross-platform Mac+Win fleet builds so here goes

Hope this shares some real value.

100+ "free-range" office laptops. The kind that lag when a 3rd Chrome tab opens. No dGPU. Battery lasts 40 mins if you're lucky

Qwen 3.6-35B-A3B on each Studio via Ollama. A LAN router + ComfyUI + img gen for the rest

Why this exists:

Our team needed auto-generated social media content, product posts, images, scheduling, research docs... without:
- uploading business docs to some random cloud
- leaking internal convos to whoever's API we're using
- paying per-seat SaaS tax for smth we can run ourselves

We ain't a dev shop. Half the team is happy with Windows Update weekly, the other half on Mac. "Terminal" is a scary word. They just click "generate" and get output.

The old way was tragic, one machine, one LLM, one API key. Growth team runs a SQL query -> model freezes -> everyone else's agents hang. System looks alive, nothing comes out. Then 3 more people retry the same query. Death by single-queue

The queue:

Conventional answer is scale vertical bigger GPU, more VRAM, one mega-machine. Doesn't fix the single queue. One heavy query still freezes everything. And when that machine dies, everyone stares at "connection refused." Going horizontal instead 3 machines, each independent, each with its own queue means nobody blocks nobody. A router sends each request to the least-loaded engine. Linear throughput scaling, fault tolerance, and you expand by adding 1 more machine, not forklift-upgrading the whole rack.

Grid (the router we use) saves us because it doesn't have one queue it has per machine. Each engine queues internally. Heavy query -> machine A. Caption gen -> machine B. Nobody blocks nobody. 3 machines = 3 queues, each clearing at ~80 tok/s on Qwen's MoE. A heavy analysis might take 30s on one machine while the other two serve 20 lightweight requests at the same time.

Bottleneck went from "one queue everyone fights over" to "how to stack 3 Mac Studios without them falling over." Way better problem

The math:

M2 Ultra = 800 GB/s bandwidth. 192GB unified memory. Qwen 3.6-35B-A3B (MoE, 3B active) at 32-64K context per session. Per Studio handles ~17 concurrent sessions. 3 Studios = ~50 concurrent. At 25% concurrency, that's ~200 employees. 500-token response at peak: ~12s. Wait time under half a second. Headroom for days.

24GB VRAM hits OOM at ~2 concurrent 64K sessions. Not a dig, just physics of the hardware.

The cost:

3 Mac Studios: ~$17k total
Power draw all 3 under load: ~300-385W
No data leaves the building

Vs cloud equivalent comparable throughput but your data stays in-building

Scale:

Vertical scaling means buying a bigger machine. But you hit a ceiling, no bigger GPU exists, no more VRAM slots. Every upgrade means migrating everything, reconfiguring, downtime. Horizontal instead? Add another Mac to the stack. The router picks it up. 3 Studios today, 4 tomorrow, 6 next quarter. The ceiling isn't the hardware it's how much desk space you got left.

Things you should keep in mind before stacked Mac Studios like this:

1. ⁠LAN or nothing. No LAN = no agents. If the internet bill goes unpaid, or your wifi goes down ur entire fleet disappears. Just a room full of people staring at "connection refused"
2. ⁠Employee takes laptop home at 6PM? They now own an expensive paperweight. Agents live in office LAN. "It's a privacy feature not a bug." Remote Desktop may help if they really need it. Or tell them to touch grass idk
3. ⁠Not zero-config yet. Each laptop needs an agent gateway configured once (~10 mins). My non-devs can't do that. Looking for a "my auntie can join the fleet" solution if anyone's solved this

Hey everyone,

A few weeks ago I bought a Bambu P1S as a birthday gift for my son. Watching him set it up got me reflecting on my own hardware workflows and how much has shifted. I pulled out my notes from a decade ago versus what we run today, and the contrast is wild.

Whether you are a solo builder, a startup, or just a dad introducing his kid to hardware, the barrier to entry has collapsed on the hardware side. Here is my breakdown of the 2026 reality of 3D printing, rapid prototyping, and the new "CAD wall."

1. The Hardware Side is Unrecognizable

Cost-per-gram of capability dropped roughly 6-8x in 10 years.

• 2016: A Prusa i3 MK2 set you back $699. Print speed maxed at 60 mm/s for clean parts. Bed leveling meant manual paper-shimming. Material catalog was PLA, ABS, and a heavy dose of "good luck."
• 2026: An Elegoo Centauri Carbon costs $300 for a fully enclosed CoreXY system. Bambu A1 mini ships with lidar auto-leveling, and 500 mm/s is the speed baseline. Budget-tier quality beats what cost $3,000 a decade ago. The Bambu H2D at $1,749 brings dual nozzles, 65°C heated chamber, and an optional laser.

Modern machines are mature utility appliances. Resonance mapping and automated failure detection mean you hit print and walk away. The hardware has stepped out of the way of creativity.

1. The Micro-Factory: Prototype to End-Use Production

For startups and solo builders, this leap has democratized rapid prototyping against traditional CNC or injection molding.

Speed to market: Instead of sending files out and waiting weeks for quotes, only to find a screw hole misaligned by 1mm, you can iterate on a custom chassis three times in an afternoon.

Material evolution: The catalog now includes Carbon Fiber-reinforced Nylon (PA-CF), Glass Fiber-reinforced PETG (GF-PETG), Polycarbonate (PC), and TPU shore variants.

Small-batch viability: Because 3D printing is additive, material overhead stays cheap. For customized products and low-volume runs, 3D printing competes with traditional manufacturing. You can print load-bearing structural parts with generative lattice designs that are not feasible to cut on a CNC.

1. The Software Paradox: Slicers Evolved, CAD Didn't Get Easier

While hardware skyrocketed, the design pipeline mostly didn't move.

Slicers got better. OrcaSlicer is impressive, Bambu Studio handles AMS multi-material smoothly, PrusaSlicer is mature.

But CAD design tools? Functionally the same gap as 2016. The learning curve hasn't shortened. You still need to learn Fusion 360, FreeCAD, SolidWorks, or Onshape. The engineering knowledge required to design a printable part (tolerances, snap fits, threads, support orientation, shrinkage compensation) remains unchanged.

1. Testing the 2026 AI Text-to-CAD Crop

To see if this skill gap could be bypassed, I tested the current crop of generative AI text-to-CAD tools.

The honest 80/20 rule:

Where AI Text-to-CAD Wins: decorative geometry, printable meshes for figurines and non-load-bearing components, fast shape exploration when you have a vague concept, and lowering the barrier for standalone projects like a phone stand.

Where AI Text-to-CAD Breaks: dimensional accuracy for parts with 0.2 mm clearance, multi-body assemblies beyond a single bracket, standardized threading and bearing seats requiring industrial spec, and reasoning about print orientation for structural strength or material shrinkage compensation.

Current public tools solve the first 80% (the visual concept). The last 20% (engineering precision) is where actual hardware lives, and that's the gap untrained users can't bridge alone.

The 2026 Reality for Builders

I put this to the test on a hardware project requiring custom enclosures, brackets, and cable management. I tried an AI-first workflow for the simpler pieces but immediately had to fall back to traditional CAD for anything structural.

If you know CAD: 3D printing is finally a viable end-use technology. Hardware is no longer the bottleneck, and material selection covers most engineering use cases.

If you don't know CAD: AI text-to-CAD gets you to a visual prototype faster than ever. You can make simple functional items without opening advanced software. But the moment your part needs to interface with something else with precision, you are back to learning parametric modeling or outsourcing.

The skill barrier didn't disappear. It just moved.

Curious what the community is seeing:

For those who started 3D printing recently, where did you hit the CAD wall?

For veteran builders who learned CAD before these AI tools existed, are you integrating generative tools into your daily workflow, or sticking with traditional modeling?

We just finished an on-prem inference rig for our team at the workshop. Sitting next to the bench right now serving the team. Sharing the build because the lessons learned matter more than the spec sheet, and I want to compare notes with anyone running similar setups.

The build:

• 8x RTX 4090D, 192GB VRAM total
• Dual AMD EPYC 9004 Genoa
• ASRock Rack GENOA2D24G-2L+ motherboard
• 4x 2000W PSUs on a distribution board (8000W total)
• Custom CNC'd 4U chassis (off-the-shelf doesn't fit this)
• 12 case fans on single hub, front-to-back airflow
• Real-world draw under inference load: ~4,600W

What we run on it:

• Production: tensor-parallelized 70B
• Staging: 32B fine-tune running in parallel
• Workflows: quantized DeepSeek-V3 kept warm for agent automation

No reload penalties, no rate limits, no API bills.

---

Why dual-socket Genoa, and the PCIe lane math:

We spec'd these CPUs for the lanes, not the cores. CPU utilization stays under 40% even under sustained concurrent multi-model serving. The lanes are the product.

Single socket EPYC 9004 = 128 PCIe Gen5 lanes. Dual-sockets get more complicated. Some lanes get repurposed for inter-socket Infinity Fabric (xGMI). Each xGMI link uses 16 PCIe lanes.

• 4-link xGMI (default): 128 lanes total for PCIe
• 3-link xGMI: 160 lanes total for PCIe
• Plus 12 PCIe Gen3 lanes from the I/O die (M.2 territory)

The ASRock Rack GENOA2D24G-2L+ exposes 20 MCIO connectors x 8 lanes = 160 lanes, which means it's running 3-link xGMI. That's the configuration you want for an 8-GPU build.

Lane budget for the rig:

• 8 GPUs at full Gen5 x16 = 128 lanes
• 32 Gen5 lanes + 12 Gen3 lanes remaining = storage, NICs, platform overhead

AMD's HPC tuning guide section on xGMI link configuration explains the tradeoff between inter-socket bandwidth and available PCIe. Worth reading if you're speccing one of these.

---

The MCIO cable trap:

The board has no traditional PCIe slots. Out of its 20 MCIO connectors, 16 are aggregated through adapter cards to deliver Gen5 x16 to each of the 8 GPUs.

MCIO cables look symmetric. They aren't. There's a host end and a device end marked by a small embossed triangle. We plugged six in correctly and two rotated 180° on first build.

Symptom: those two GPUs enumerated at PCIe Gen1 x4 instead of Gen5 x16. Inference throughput on those two cards dropped to about 10% of the others.

We spent two hours suspecting the GPUs before our hardware guy pulled out the manual and pointed at section 2.6. Confirm orientation at both ends before you mount the cards over the riser adapters. Once GPUs are seated, you can't see the MCIO connectors anymore.

Save yourself the debugging time.

---

Power and thermals:

• 8 GPUs x 425W = 3,400W from GPUs alone
• Plus dual CPU, 12 fans, drives, platform overhead
• Real-world inference draw: ~4,600W

Splitting across 4 PSUs lets us survive a PSU failure without the box going down. 3,400W of GPU heat in a sealed 4U requires real airflow geometry. Without it, the cards throttle and you lose the throughput you paid for.

Custom chassis because off-the-shelf doesn't fit 8 dual-slot GPUs + dual EPYC + 4 PSUs + 12 fans. Rack-mount server chassis exist at this density but they're loud as a 737 and built for datacenters. We needed something that lives next to a desk in a workshop.

---

This kind of rig isn't for everyone. If your team is under 100M tokens/day or under $30K/month on API spend, it's clearly not for you. The hardware cost amortizes around those numbers depending on which models you serve.

ROI math aside, the sovereignty dimension matters more than the financial one once you've thought about it. Your customer data doesn't leave the box. Your fine-tunes don't sit on a vendor's storage. The cost saving is real. The sovereignty is the actual product.

Curious what other teams are running locally. If your team moved from API to your own hardware, what was the trigger? Cost, sovereignty, rate limits, something else? And for teams still on hosted, what's keeping you there?

Hey everyone,

After sharing about my team's 8×GPU build and receiving a lot of great discussion, I want to dump my notes on putting together a dual RTX 5090 here for anyone else building a multi-GPU workstation.

Here's the technical breakdown of the build and how to get it running without thermal throttling or PCIe issues.

Hardware Architecture (BOM)

To handle two 5090s, a standard consumer platform can work, but physical spacing and PCIe lane allocation often become limiting factors with dual 5090s. I chose a workstation platform to avoid those constraints:

• Motherboard: ASUS Pro WS W790-ACE (paired with a Xeon W5-3425).
• CPU: Intel Xeon W5-3425 (12C/24T, Intel ARK lists support for up to 112 PCIe 5.0 lanes) 
• RAM: 4× DDR5 RDIMM ECC.
• Storage: 1TB NVMe (boot only, models need a separate, larger drive)
• PSU: 1600W server-grade unit. Dual 5090 sustained draw is ~1150W+ under load; 1600W gives safe headroom
• Interconnects: 2× PCIe Gen 5 riser cables + 2× 12V-2x6 (ATX 3.1) 600W power cables for GPUs
• Cooling: Dedicated LGA 4677-compatible CPU heatsink + 4× 120mm high-static-pressure case fans

Note on RAM: The W790-ACE specifically requires DDR5 RDIMM (Registered ECC). Standard consumer DDR5 UDIMMs are not on the QVL and will not boot. Check the ASUS QVL before buying.

Mechanical Layout & Thermal Mitigation

Plugging both GPUs directly into adjacent PCIe slots on the board creates an immediate thermal bottleneck due to restricted air intake.

• GPU Decoupling: I used PCIe Gen 5 riser cables to physically offset the GPUs from the motherboard. The cards are mounted to a custom chassis frame plate using brass standoffs and hex screws to carry the structural load and eliminate GPU sag.
• Airflow: Separating the cards allows 4× high-static-pressure fans to push air directly through the heatsink fins (2 intake / 2 exhaust). Power cables for the GPUs must be routed outside the intake path.

PCIe Lane Configuration, Important Clarification

The ASUS Pro WS W790-ACE features 5× physical PCIe 5.0 x16 slots, but they share bandwidth based on strict bifurcation modes: x16 / x16 / x16 / x0 or x8 / x16 / x8 depending on which slots are populated. Slot 4, for example, is wired differently and cannot run at full x16 when other specific slots are active.

To avoid performance degradation, verify the lane allocation table in the ASUS manual for your exact configuration:

* For this 2-GPU build: In my configuration, populating Slot 1 and Slot 3 allowed both GPUs to negotiate PCIe 5.0 x16 links.  

* Depending on the slot population scheme, some slot combinations may negotiate x8 links or disable other slots entirely. Always trace your lane allocation against the ASUS manual before mounting the riser cables.

Does x8 matter for LLM inference anyway? Benchmarks consistently show that once model weights are fully loaded into VRAM, token generation is limited by the GPU's internal memory bandwidth, not the PCIe bus. However, for initial model loading speed and inter-GPU communication overhead, forcing full x16 is still the proper engineering approach.

Custom CNC Chassis, Structural Rigidity & Airflow Optimization

Instead of a conventional steel PC case, the frame is CNC-machined from aluminum plate. The goal is not aesthetics, but structural integrity. Dual RTX 5090s are extremely heavy cards, especially when mounted via Gen5 risers. The aluminum structure provides a rigid mounting surface that minimizes flex and prevents long-term mechanical stress on the riser assemblies.

The side panels use a truss-style lattice pattern rather than solid walls. This reduces unnecessary mass while preserving panel stiffness and allowing unrestricted airflow across both GPUs. With the cards physically separated, the open-frame layout lets the cooling fans deliver air directly into the heatsink fin stacks instead of fighting the airflow restrictions commonly found in conventional tower cases.

Critical BIOS Configuration

The default BIOS configuration may lead to resource-allocation issues or multi-GPU initialization problems in some setups. Manually configure the following:

Above 4G Decoding (Required)

Advanced → PCI Subsystems Settings → Above 4G Decoding → ENABLED

Maps memory resources above the 4GB boundary. Without this, the system may not have sufficient PCIe MMIO address space to map multiple high-memory GPUs correctly (2× 32GB = 64GB).

Resizable BAR (Strongly recommended)

Advanced → PCI Subsystems Settings → Re-size BAR support → ENABLED

Allocates the full GPU framebuffer to the CPU simultaneously instead of chunking data through a 256MB aperture. May reduce latency during heavy tensor transfers.

ASPM & C-States (Recommended)

Disable ASPM (Active State Power Management) and deep CPU C-states. This prevents PCIe lanes from entering low-power states mid-workload, which can occasionally introduce latency spikes or stability issues during sustained multi-GPU workloads.

Memory Profile (Recommended)

Enable XMP if your RDIMM modules support it; otherwise the board will default to JEDEC SPD timings.

Fan Curves (Optional)

Tune fan curves in BIOS or via software after confirming thermals under sustained load.

Power Connector Safety Note

The RTX 50 series uses the 12V-2x6 connector (ATX 3.1 standard) — this is the updated revision of the older 12VHPWR (ATX 3.0). They look nearly identical and share the same pin-out, but 12V-2x6 has longer power pins and shorter sense pins to prevent partial-seating failures that caused connector melt issues on the RTX 4090 generation.

When connecting:

• Use only 12V-2x6 rated cables from your PSU, or the bundled adapter from the GPU box
• Push until you hear/feel the click. A partially seated connector under 575W+ load is a fire risk
• Do not bend the cable sharply at the GPU end or let a side panel press against it

Post-Boot Verification

Once the OS is up, run nvidia-smi or nvtop to verify:

1. Both GPUs are detected
2. PCIe link speed shows Gen 5 at expected width for your slot configuration
3. Power limits match factory spec (~575W per card)

Then run a sustained matrix multiply (e.g., via PyTorch or llm-bench) to confirm thermals stay stable before deploying any model.

Total VRAM

2× RTX 5090 = 64GB aggregate VRAM across two GPUs. Since consumer cards lack physical NVLink interfaces, you are relying entirely on software-level parallelization (Tensor Parallelism via vLLM/SGLang, or layer-wise splitting via llama.cpp) to utilize this aggregate memory capacity. 

This aggregate capacity allows 70B/72B-class models to remain fully resident in GPU memory without offloading to system RAM.

However, your quantization target directly limits your context window scaling:

* At Q4_K_M (~42-43GB weights), 32k context is generally achievable, although actual limits depend on framework, KV cache settings, and batch size.

* At Q5_K_M (~49-52GB weights), the overhead is tighter; pushing to a full 32k context can push the 64GB boundary to its absolute limit once the KV Cache and CUDA context overhead scale up.

* Avoid Q6_K for 70B models if you need long context, the weights alone occupy ~58-60GB, leaving insufficient headroom for high-token KV cache, leading to imminent OOM or severe offloading performance penalties.

Happy to answer questions on riser config, thermal telemetry, or slot bifurcation specifics.

Started with one thing: running Ollama on my Mac Mini for coding. Then I got a 3090 secondhand and built a Linux box for bigger models via vLLM. Then I realized my old gaming PC could actually do ComfyUI for image gen. Three machines, three different ways to start/stop them, three URLs to remember.

I had this stupid paper taped to my monitor with IPs and ports written in pen.

Tried systemd services with reverse proxy. Worked but every time something changed I'd spend an hour debugging. You know the feeling when you ssh into a machine and forget which service file goes where? That was my life.

The breaking point: a friend lent me a 4th machine for a week. I never even set it up because I couldn't be bothered to wire it in.

So I built Grid. First version was a Python script held together by duct tape. Worked for about 5 days before I had to restart it every time my kid rebooted the router.

The "aha" moment was when I stopped thinking about this as "routing" and started thinking about it as "unification." The reframe that stuck:

"You already run Ollama on your Mac, vLLM on your GPU box, LM Studio on your laptop. Point Grid at them — now they're one private endpoint. Your app talks to all your machines and all your engines at once, and you replaced nothing. Plus images and video, same endpoint."

it sits on top of everything yoItu already have. No migration, no new runtime to learn, nothing leaves your network.

Repo: https://github.com/autonomous-ai/autonomous-grid

What I fucked up:

• Wrote the proxy in Python first. Under load it was garbage. Rewrote in Rust.
• Auto-discovery doesn't work on macOS out of the box (UDP broadcast blocked). Had to add a fallback.
• No telemetry = no data when things break. Added structured local logs instead.

Tech details for the curious:

• One command to start the server, one command per machine to join
• Auto GPU discovery via LAN
• One OpenAI-compatible endpoint for everything
• Works with Mac/Linux/Windows, no Docker needed
• Fully offline. Not even "we don't share your data" — there's literally nothing to share.

Current debate: CLI only or add a web dashboard? I like CLI because it's clean. But "seeing" your cluster is pretty satisfying. What do you guys prefer?