←back to thread

223 points codekansas | 1 comments | | HN request time: 0s | source

Hi HN, I'm Ben, from K-Scale Labs (https://kscale.dev). We're building open-source humanoid robots.

Hardware video: https://www.youtube.com/watch?v=qhZi9rtdEKg

Software video: https://www.youtube.com/watch?v=hXi3b3xXJFw

Docs: https://docs.kscale.dev

Github: https://github.com/kscalelabs

HN thread from back in May: https://news.ycombinator.com/item?id=44023680

I started K-Scale because I really wanted a humanoid robot to hack on, so I knew that if I built one, I would have at least one customer. It was before the Unitree G1 came out so the cheapest option at the time costed over $50k, but I figured I could build one for about $10k using COTS (Commercial Off-the-Shelf) components, which would be a much better price point for indie hackers and developers.

We built the first version using some 3D printers and parts that I bought off of Amazon and Alibaba. It was not great, but it let us build out the full pipeline, from designing and building the hardware to training control policies in simulation. We actually did most of this in about two months, and had a standing, waving robot by YC Demo Day (although it wasn't good for much else!).

Since then, our focus has been on figuring out how to go from a hobby-grade robot to a consumer-grade robot, without inflating our BOM (Bill of Materials, i.e. cost of all the parts) or having to set up our own factories. This is surprisingly difficult. A lot of the supply chain for robotics components currently goes through China, but tariffs have made it difficult to rely on Chinese suppliers for components. Also, even a $10k price point is pretty expensive for most customers, for a humanoid robot that has fairly limited capabilities.

Our solution to this is to open-source our hardware and software. This makes it easier for us to navigate tariffs and manufacturing challenges. By making our reference design public, our suppliers have a much easier time figuring out how to offer us competitive solutions, and our manufacturing partners are able to more easily adjust our design for their production processes.

On the demand side, the basic problem with humanoid robots is that they're mostly useless right now, and it will probably be a long and fairly capital-intensive journey to make them useful. My expectation was that there is a large pool of latent interest from people like me who are interested in hacking on humanoids, and that this customer segment is a much better customer segment to sell into than more traditional business-focused robotics applications. As someone in this customer segment myself, I felt that open-source software and hardware would be a strong value proposition, particularly for developers exploring bringing humanoids into their own business verticals.

More philosophically, I think it is important that there is a good, open-source humanoid robot. I think the technology is likely to mature much more rapidly than many people currently expect, and the idea of armies of humanoids owned by some single company walking around is pretty dystopian.

Right now, we're selling our base humanoid robot, K-Bot, for $8999. The main reason we're selling it now, instead of waiting to do more R&D, is because we're trying to negotiate volume prices with our own suppliers before we do final DfM (Design for Manufacturing). For example, we are able to negotiate better volume pricing for actuators and end effectors than what the average indie developer would be able to get for low-volume orders.

However, a lot of the people who want to buy a humanoid robot today do so because they want a completely autonomous robot to do all their chores, which is a pretty hard (although exciting) thing to build. To square this circle, we're offering a "Full Autonomy" option - it is the same robot hardware, but we will provide free hardware and software upgrades until we are able to make the robot fully autonomous. This way, we can have some extra cash upfront to kickstart development, and start to build a core group of people who are aligned with helping us improve the robot's capabilities across a diverse set of environments. From our customers' perspective, it's a way to de-risk buying a first-generation product from a young hardware company, and to have a bigger influence on how the technology unfolds.

The best part about building open source software and hardware is getting torn apart by people smarter than us, so we'd love your feedback!

Show context
chrsw ◴[] No.44457393[source]
I have some technical questions about feet.

Human feet have metatarsophalangeal joints connecting the toes to the rest of the foot. But humanoid robots don't have these (at least, the vast majority don't). Why? These joints are very useful.

Also, the bottom of the human foot is soft and has thousands of nerve endings. Can we really expect robots to get anywhere near human mobility performance without this level of compliance and sensory sophistication?

replies(3): >>44457590 #>>44457627 #>>44466226 #
cpgxiii ◴[] No.44457627[source]
Feet/ankles on humanoids are really hard mechanically. In many ways the kinematic requirements for the ankle are similar to a wrist, but while the wrist of a robot arm is the least-heavily-loaded, the ankle area can be the most heavily loaded. Humans get away with it by having most of the highly-stressed actuators in the lower leg, not the ankle itself, whereas many humanoid robots end up putting more of the actuators in the ankle assembly itself.

In general, I think the best way to think about the differences between human muscles and robot actuators is that human muscles are simultaneously incredible in terms of strength and power density, and also incredibly fragile. Robot actuators are fairly robust, but comparatively poor. Humans are essentially falling apart at all times, but the repair mechanisms in the body do a good enough job that it doesn't matter (although you probably know someone with a "career-disruptive/ending" sports-related injury that shows these mechanisms have limits). Robotics is a long way away from making actuators that can be fixed online in such a process. Even cable stretching in cable-driven mechanisms remains hard to handle effectively, and that's one of the simplest types of mechanism wear.

replies(2): >>44457908 #>>44457944 #
1. codekansas ◴[] No.44457944[source]
This is a much better answer than mine