Norirobotics
Hey HN, I’m Antonio from Nori Robotics (https://norirobotics.com). We build a $1,688 bimanual mobile robot in San Francisco for robotics developers and researchers. I started working on Nori while doing robotics research at Columbia. I was teaching robots through human demonstrations, but getting my hands on affordable hardware was difficult. Most labs have one or two expensive robots, which makes it hard to collect large datasets, run long experiments, or test across several robots. So I built my own. After seven iterations the latest Nori has: * 19 degrees of freedom * Two 7+1 DOF arms with a 1.5 kg payload per arm * A 55 kg telescoping lift * A differential wheeled base * Four 720p, 30 fps RGB cameras * 2D lidar * A dual microphone array with full-duplex voice communication * A 432 Wh battery * A Raspberry Pi 5 with 4 GB RAM (SLAM and safeties are run on board, heavier ACT and VLAs must be run from a computer via LAN or a server via WAN) Getting this under $2,000 was the main engineering challenge. Nori has more than 100 moving and structural parts, so costs add up quickly across actuators, bearings, wiring, power delivery, and assembly. Some main choices we made to get the cost low was using high-ratio servos instead of QDD motors, and using a wheel base instead of legs. We assemble each robot in San Francisco and have designed it to be easy to manufacture and repair (we offer 3D files to print repairs). Our open SDK includes teleoperation and demonstration tools: https://github.com/Nori-Robotics/nori-sdk-py We also built a browser-based simulator so you can try it out: https://lab.norirobotics.com/nori/model We’ve shipped our first robot and are building the next batch. Eventually, we want people without robotics experience to teach Nori tasks and share them with other owners. Currently the hardware is already capable of basic cleaning tasks, opening drawers, restocking shelves and pouring beers. Here is a video of Nori doing things: https://youtube.com/shorts/VRfVXHfQvD8 We make money by selling the hardware for $1,688, with optional paid software on top. Parts of hardware are open source. More details are in our hardware paper: https://doi.org/10.48550/arXiv.2605.16537 If you work in robotics, what would you build with a robot at this price? What would you change about the hardware?
AI Analysis
Analysis coming soon.
Similar Products
Capgo
Instant updates for Capacitor apps. Ship fixes in minutes, not weeks. Push OTA updates to users without app store delays.
OpenAlternative
Open source alternatives to popular software. Over 1 million users replaced their proprietary tools with open source software. Discover the best alternatives and join the movement.
Orthogonal
Hey HN, we're Bera and Christian, and we're building Orthogonal. Orthogonal gives AI agents one integration to discover, access, and pay for APIs. Think OpenRouter for the APIs that AI agents use. We currently have 50+ API providers and 700+ API endpoints across company, people, financial, and web data, available through our MCP server and SDK on a pay-as-you-go basis. We started with GTM related APIs and are now expanding the catalog. You can try at https://www.orthogonal.com/. You'll need to create an account to use the chat or connect the MCP/SDK. An example prompt for the chat or MCP: Find AI infrastructure startups that recently raised a Seed or Series A and return their founders, LinkedIn profiles, and relevant company data. When we heard about https://x402.org/, we saw an opportunity to make APIs easier for agents to pay for. Instead of an agent needing to manage an API key and billing for every API, what if it could just pay for each request? So we started onboarding existing API providers onto x402. Then we realized an agent cannot pay for an API it doesn’t know exists. It also needs to figure out which API can complete the task and how to use it. We also found that putting every small API payment on-chain did not always make sense. If both sides already have accounts with Orthogonal, settling internally is simpler. So we separated API discovery and access from the payment rail. Today, payments can happen through Orthogonal credits, x402, https://mpp.dev/, or https://www.circle.com/nanopayments. The problem we're working on now is API selection. If five APIs can answer the same request, which should the agent use? The cheapest might have worse coverage. Another might be more accurate but slower. We're working on using price, latency, reliability, and result quality to help agents make those decisions. How are you currently giving agents access to paid APIs? And if you gave an agent a budget, would you trust it to choose which API provider to spend it on?
Murmell
Hey HN! I'm Moss'Ab. Murmell (https://murmell.com) is an infinite canvas where coding agents run together in the cloud instead of on your laptop. It's like Google Docs, except the other editors are you, your teammates, and a set of agents all working in the same canvas. Short demo: https://app.murmell.com/demo The idea came out of a YC hackathon. We were trying to build the thing under extrem pressure, deploying at the very last minute, but with several agents working in parallel, all the branches collided. Everything broke at the worst possible moment and we spent the end of it untangling instead of building. We didn't win. Murmell is the thing I wished we'd had that day: one place where the agents and the people can see each other work, on machines that don't belong to any one laptop. Each canvas gets its own machine in the cloud. Close your laptop and the agents keep going; open it again anywhere, or have a teammate open the same canvas by sending him the link, and you're inside the same session rather than a copy of it. The work stays exactly where you left it : same branches, same dev server still running, so an agent picks up mid-task instead of starting from scratch. And you can literally collaborate with your team like google docs, it's se same system, read of edit link, they connect they can type on your terminal, you can see their mouse, wich terminal they're typing in. And you can interact wich each other sessions, it's pretty useful instead of sharing a screen, copying a prompt, etc. The hardest part was building the cloud infrastructure, trying to make it scalable, and to manage the sessions to make the best experience possible: when the VM shuts down, it snapshots everything and restores everything when you come back, even the conversation with your terminal, it's stored with a system that i built like obsidian wich also make you save a little bit of tokens. So the answer to that hackathon is file claiming. Before an agent works on something, it claims the paths, it's an exclusive lease with a TTL, so nothing stays locked forever because an agent died mid-task. And if another agent asking for the same file gets denied, the denial tells it who holds it, how long is left, and to either pick other work in its scope or message the holder (the agents can communicate through the board) A watcher classifies every write, so if anything writes inside someone else's claim it shows up on the canvas as a collision right then, instead of as a merge conflict you discover an hour later. And when an agent is done, it can hand its claim to the next one. And agents never hold your provider keys either, they get a token, and a proxy on the container's loopback swaps it for the real key on the way out, which makes a leaked token worthless outside that container. Murmell is paid. I've put prices at 50% off for now, because it's still not where I want to take it yet. It is fully usable though: I develop Murmell with Murmell, every day (and tbh it's save soooo much time to us with my cofounder) And to be fully transparent with the actual prices it costs us much than we are earning but the goal is to collect feedback to make Murmell as good as possible For context: I'm 19, a 4th year computer engineering student, and I've been on this for about three and a half months, day and night. I discovered claude code after my father showed me first Windsurf (today Devin) for a python homework in 2024, and i think i never went somewhere without my laptop since then lol. So feel free to comment or to give feedback, or even subscribe to support the project :)
Sesame
I have been working on Sesame, an open-source password manager that keeps your vault local by default. You don't need an account to create or use a vault, and the hosted service never receives the vault itself. It's still early software and the independent security review isn't finished yet, so I am mainly interested in feedback, testing, and people looking through the code. (Linux support is yet to be released on v0.1.2, but currently is in the works.)