Robot Software Designed Together as a Team: An Interview with Diden Robotics CTO Soonpyo Kwon

"People only see the robot moving well. But to get even one of those motions onto a real robot, code from many different people has to mesh without colliding."

That is why Soonpyo Kwon, CTO of Diden Robotics, puts a structure built for collaboration ahead of the code itself as the core of the company's software. For a single robot to move, code from the engineers responsible for locomotion, perception, and decision-making has to run at the same time inside one body.

Kwon researched reinforcement learning-based locomotion control and vision-based mapping at KAIST's HUBO Lab. Today, as a co-founder and CTO of Diden Robotics, Kwon builds the technology roadmap and leads the software division. Notably, Kwon set up a separate Platform Software team dedicated to the common foundation that puts each engineer's controllers onto the real robot.

Diden Robotics is a manufacturing company that builds hardware, but as Kwon explains, its collaboration structure was designed like that of a software-first company. We asked how individual projects in a lab differ from collaborative projects at a company, and where Diden Robotics' software is headed.

Mapping the Way for Robots Headed to the Shipyard

Q. Tell us about your role at Diden Robotics.

As CTO, I'm building the technology roadmap that will get our robots into shipyards. My main role is to divide that roadmap among the teams and take in the feedback that comes back from them.

As an early startup member and Diden Robotics' first CTO, I also help everyone learn the systems the founders built so they can keep using them well for a long time. Outside the company, I explain how our technology can be used and coordinate in between so that it can lead to sales.

Our software division has four teams. The Motion Intelligence, Decision Intelligence, and Vision Intelligence teams work on how the robot moves, makes decisions, and perceives its surroundings. The fourth, the Platform Software team, is a little different. It builds the common foundation that lets the controllers and features from the other three teams run together on a real robot.

▲ A gait learned in simulation (left), transferred to a real Diden Spider (right). Source: Diden Robotics website

Choosing the Field I Knew Least: Robotics

Q. How did you get into robotics?

I studied mechanical engineering at Sungkyunkwan University, and I've always enjoyed studying. Among engineering fields, mechanical engineering takes a lot of math, so it suited me. It wasn't that I was especially drawn to building things; I wanted to go to graduate school and learn more. So I asked myself where I could learn the most, and which field I knew the least about. The answer was robotics.

That's how I joined HUBO Lab at KAIST. HUBO Lab won the 2015 DARPA Robotics Challenge in the United States. I may be biased since I came from there, but I think it's one of the top robot-building labs in Korea. Professor Hae-Won Park*, who now leads the lab, is truly remarkable, and the researchers working under him each have a distinct style, work hard, and are very good at what they do.

* Professor Hae-Won Park: Professor of Mechanical Engineering at KAIST and director of the Humanoid Robot Research Center. He received a U.S. National Science Foundation (NSF) CAREER Award (2018), and his research on MARVEL, a legged robot with magnetic feet, was featured on the cover of Science Robotics (2022). He currently serves as CSO of Diden Robotics.

Q. When did you start thinking about founding a company?

I kept thinking about it after I started graduate school. I didn't know why at the time, but looking back, I think what appealed to me was having the value of my work judged fairly.

Usually, it's hard to measure how much work you've done, and hard to compare yourself with others. I think a startup has relatively clear standards for what you did well. Whatever the outcome, it shows exactly where you stand, and I actually found that reassuring.

I kept thinking about what kind of company to start, but back then there weren't yet robots ready to be applied in the field, so I couldn't find the right idea. Then, while I was in graduate school, the AI boom took off, and I felt the door was opening for robots to move into the real world.

Around then, lab colleagues were selected as an Excellence Team (2nd place) in the second half of 2022 at E*5 KAIST*, KAIST's student startup program, with the idea of putting magnetic feet on a quadruped robot so it could climb steel walls. I had always been thinking about starting a company too, so as we talked, our goals aligned and we started together. The idea was good, and the chance to work with HUBO Lab members was a big factor too.

* E*5 KAIST: KAIST's flagship student startup support program, run by the KAIST Startup Institute since 2012.

When Code Written Alone Becomes the Team's Code

Q. Were there challenges in developing software at a company that you hadn't known about in the lab?

Plenty. The first that comes to mind is collaboration. In the lab, writing code and running experiments is almost entirely individual work. Fellow lab members may help with experiments, but how you develop and build better modules is entirely up to you. Your code effectively becomes a personal project.

A company is different. Logs need to keep accumulating, and your work has to combine with everyone else's to form one larger result. If a lab is where you create small, deep works, a company is where the whole has to run organically, even if it goes a little less deep.

Each task is hard in its own right, so highly capable engineers put their own ideas forward clearly. That means there's a lot of friction when we merge their code into one. Everyone having a strong philosophy is unavoidable, so in the end, it's not about whose way is right, but about what we choose. That's why we decided to put a structure many people can use together ahead of code that one person writes well.

Our software has V1 and V2, and we're now moving to V2. The most important keyword for V2 is collaboration. If V1 was code focused on the basic design for moving the robot, V2 is code written with collaboration fully in mind, so that many people can develop together.

Traditional ways of collaborating already existed, but AI is now changing the very way software is developed, so how to bring that change into collaboration is another hard question. That's also why we're moving to V2.

Q. What's it like working with the hardware team?

There's always friction, and the same goes within the software team. What matters is working through it well. One of our strengths is that our leadership has worked across both hardware and software, full-stack. Leaders who understand both sides can mediate in between.

For example, say a sensor on the sole of a magnetic foot isn't working as expected. The software person's first thought is, 'The sensor is broken.' But the person who built the sensor believes they built it well, so they might think, 'Why is it stepping so hard?' In reality, you could make the gait gentler, or build a feature in software that detects sensor anomalies.

If someone just says, 'The sensor is broken,' it isn't wrong, but the hardware side can feel like they're shouldering the blame alone. When that happens, I add context afterward or explain to the hardware side that the person meant no harm at all.

The hardware side has strong views and equally strong logic, so when you explain things well, they understand, with something like, 'That's a shame, but fair enough.' Having many people with clear opinions is a double-edged sword, but woven together well, it leads to great results.

Q. What changed when you moved from the test site to the field?

There was a lot to consider technically. We estimate the robot's position based on CAD drawings, but structures in the field can differ slightly from the drawings.

Lighting is different, too. LiDAR performance changes with how much light reflects off steel plates, so it has to be tuned to the environment, and conditions at the test site and in the field are very different. Even lights that look like the same fluorescent lamps can differ once you analyze their wavelength bands. Checking and accounting for these conditions one by one is what makes a robot actually usable in the field.

▲ Tracking the robot's position in real time inside a structure. Source: Diden Robotics website

Why Structure Matters More Than Code

Q. Hardware strengths like magnetic feet and actuators are easy to see. What are your strengths in software?

Published technology is effectively shared by everyone. So I think what matters most is the philosophy and direction a company follows in building its software.

Robots that go into industrial settings end up optimized into the form that fits the job. That's also why, although we started with a quadruped, we also built Diden Walker and Diden Humanoid. No single form can do every job; each job has a form that fits it best.

The data used most for training in robotics today is human data. People appear in video more than anything else, and motion capture makes it easy to collect human movement. That's one reason humanoids are advancing quickly, and we can draw on that data as well. What's harder is robots that aren't shaped like people. But forms like quadrupeds, with no human data to reference, are also essential in the field. With magnetic feet, it's harder still. People have never walked on a steel wall held on by magnets, so there's no human motion to imitate in the first place.

So how to collect data for robots like these is crucial, and the key is who builds the framework for it. We're building a framework that makes it easy to collect data even for quadruped robots, by using model-based control to generate physically feasible motions directly and using them as training data.

▲ Automatically organizing data collected by the robot into a form usable for training. Source: Diden Robotics website

Q. We heard that three robots with different forms share a single software stack.

The concept itself isn't hard. If three robots share one software stack, fixing a feature once applies the fix to all three, and there's only one codebase to manage.

But actually doing it is a different story. The three robots look different and move differently. Running them on one software stack takes real effort from the engineers doing the hands-on work, and their ability to collaborate has to be excellent.

The people who were developing Diden Spider, Diden Walker, and Diden Humanoid are all coming together on this structure. So I see it less as an impressive feat of technology and more as an example of how well we collaborate.

▲ From left: Diden Spider, Diden Walker, and Diden Humanoid. Source: Diden Robotics website

Q. From an engineer's point of view, what's the standard for saying a company is good at software?

The philosophy of our software is collaboration itself. Our current team members, and those who will join us, can all build their own controllers on their own. But getting a controller onto a real robot is a very complicated process. What defines our software is that we've made that process easier from a collaboration standpoint, and we have a separate Platform Software team to work on exactly that.

To deploy a learned locomotion policy on a real robot, you have to check everything: whether the sensors work properly, whether real-time constraints are met, and whether logs are recorded properly. It's work that rarely shows from the outside.

V2, written with collaboration fully in mind, can feel more tedious than V1 from an individual's point of view. You see parts where you think, 'Why can't I just write it this way?' But as everyone starts giving a little on those points, it becomes software everyone can use. What matters is setting aside personal preferences and taking the extra time to write code people can collaborate on.

▲ Training multiple robots at the same time in simulation. Source: Diden Robotics website

Q. How do you think Diden Robotics differs from other robotics companies?

Again, I'd say collaboration. SaaS and platform companies, whose core business is software, have this kind of collaboration structure well in place. We're manufacturing-based: we handle hardware and software together and have to move real hardware, so we couldn't copy their approach as is. Still, we believed our collaboration structure should be designed like a software company's, so we adapted that approach to our environment. I didn't set this direction alone, either. It's a conclusion we refined after hearing from team leads who came from other companies.

Of everything we adapted, I think the most important is logs. People with strong views tend to communicate in their own language, but the one language everyone shares is numbers. With good logs, instead of explaining at length, 'I tried this and it didn't work,' you can just show a log, and the conversation gets much easier.

Learning in a Virtual Shipyard, Walking in the Field

Q. How do Diden Robotics' robots learn to walk?

We carefully build elements like magnetic foot information and joint backlash into the simulator we use for training. Step by step, we're building a simulator of our own. Nothing goes in without a reason.

What matters is how we generate training data. Motion capture, video, and teleoperation are well-known ways to create data. On top of those, we use algorithms we developed in-house to generate the quadruped robot's motions inside the simulator. For example, we use an algorithm to calculate how the robot should pass through an access hole, the opening used to move between ship blocks, and generate the motion from that.

Motions generated by algorithms are accurate but slow, and on a real robot they can produce jitter that didn't appear in simulation. So we give these motions to the robot as reference data and use reinforcement learning to have it imitate them, training it to reduce the jitter and move faster.

The training environment matters, too. Based on what we've experienced, we recreate conditions in virtual environments, such as the position and shape of access holes, the many forms of longitudinals (stiffeners that reinforce the inside of a ship), and cable layouts.

▲ A virtual training environment generated automatically from ship block structures. Source: Diden Robotics website

Q. How do you plan and calculate the robot's movements inside a shipyard?

We break what the robot needs to do into tasks such as moving to waypoints, climbing walls, and passing through access holes, then group them into a single scenario. Shipyard work follows an order set by the drawings, so once that order is turned into a scenario, the robot moves through it in sequence with a single click.

When the robot is attached to a wall and a person decides where its next foot should go, the robot calculates how to move in between. It can't move in a straight line to the target; it has to fold and rotate its legs as it goes. So we use a sampling-based method that scatters samples across the space to find a path.

▲ Calculating the motion from a start pose (blue) to a goal pose (red). Source: Diden Robotics website

Robots the Field Can Trust, and a Team That Grows Together

Q. Reliability matters in industrial settings. What does software need in order to succeed 100 times out of 100?

I think succeeding 100 times out of 100 is the right goal. But robots involve so many variables that demanding that no exception ever occurs isn't realistic. What I think matters is that when an exception does occur, people don't get hurt and it doesn't lead to greater damage.

Many robots are already deployed across industrial sites. But those robots break down, too. They're still usable in the field because when something goes wrong, the robot stops and shows where the problem is. The person next to it can see that and fix it easily. So we're focused on building a system that stops the robot safely when an exception occurs and clearly reports what kind of exception it is.

In the past, I watched every experiment with my heart in my throat. With the new software, even when something goes wrong, the robot stops and tells you what the problem is. That puts both users and developers at ease. To me, that's what not failing means.

Q. When do you find working at Diden Robotics most rewarding?

I find it hard every day, and I find it rewarding every day. When a feature we worked really hard on internally delivers the performance we wanted, without any issues, in field or test-site trials, that moment is genuinely joyful. Team members who were stressed and struggling at the test site are really happy then. I love seeing that.

I'm also proud when I see our people grow. People who were new to robots or to this industry have grown a lot in a year or two, and now when I ask for something, more of it goes smoothly than I'd expect. I believe the company grows only when individuals grow, so as leaders, we constantly think about how to support each person's growth.

Q. What matters most to you when hiring software engineers?

Writing good code is a given. But everyone writes such good code that, in the end, I think what matters most is whether someone is ready to collaborate.

Of course I ask how candidates have worked, but I also share a real collaboration problem we're facing and ask how they would solve it. It's a question I don't know the exact answer to either. So the interview effectively becomes a discussion. Through it, I look at whether a candidate simply accepts what I say or offers a different direction based on their own philosophy.

Q. What do you hope to see at Diden Robotics going forward?

What I hoped for was clear from the start. On the technology side, one of the Avatar films features a six-legged walking robot moving around a construction site. That's exactly the direction we want. When I first saw that scene, I was so delighted I thought, 'Wait, that's ours!'

One of our visions is to have robots do the work people can't. It's not about replacing people; it's about robots taking on work that's hard for people to do. We envision our robots taking on that kind of work in industrial settings.

Internally, I think our team members each have a distinct style and are truly outstanding. As we've grown from four people to dozens, we've been working to solve the communication challenges that come with that growth, but it's new to me too, so I hope many experienced people will join us.

I hope we become a company where our outstanding people can make the most of their strengths, and where, wherever they go next, simply having come from Diden Robotics earns them recognition.

▲ Diden Spider, Diden Robotics' first product. Source: Diden Robotics website

What people see is a robot moving well. Behind it is a structure designed first so that code from many different people meshes without colliding. Making logs a shared language, making the robot stop and report the cause when something goes wrong, and taking what a robot learned in a virtual shipyard to walking in the field all happen on top of that structure.

That also makes clear who Diden Robotics' software team wants to work with: engineers capable enough to build controllers on their own, who speak their minds clearly while finding better choices together with the team. If you want to help build the structure that makes robots actually move, check the open positions on the Diden Robotics careers page.