From Embedded Systems to Retail Robots: An Engineer's Journey to the gemba
- Jul 13
- 7 min read
What happens when the code you write can physically move a robot carrying up to 100kg through a crowded supermarket?
In this interview, we spoke with Anthony, an embedded software engineer at MUSE, about his path from France to Tokyo, what it really means to build safety-critical firmware for retail robots, and why some of his best engineering insights come from standing in a store aisle.
Who I am and how I joined MUSE
– Could you introduce yourself and tell us how you ended up at MUSE?
My name is Anthony, I'm 29, French, and I write firmware for robots at MUSE. I have a Master's degree in Electronics and Robotics from Polytech Montpellier, part of the University of Montpellier. During my studies, I had the opportunity to work on various robotics projects, including a six-degree-of-freedom robotic arm, a hexapod robot, and drones, which sparked a real interest in the field. After graduating, I spent about three years working at a company specializing in wireless low-power sensors. That experience gave me a solid foundation in embedded systems, low-level communication protocols, and working close to the hardware, though it took me away from robotics for a while.
Then I decided to take a gap year and traveled around Asia. By the end of it, I had made up my mind to relocate to Japan. When I started looking for engineering positions here, I knew I wanted to reconnect with robotics. It had stayed in the back of my mind since university, and this felt like the right moment to come back to it.
That is when I came across MUSE. What really caught my attention was that MUSE builds its robots end to end (hardware, software, and AI) all in-house. For someone who works at the boundary between hardware and software, that kind of integration is rare and very appealing. Embedded engineers who also understand robotics are not easy to find. Most engineering graduates today focus on software or AI, and the pool of people comfortable working close to the hardware keeps shrinking. That is part of what makes this role exciting: the skills are in high demand and the problems are real. It combined everything I was looking for: embedded systems, robotics, and a product you can actually see operating in the real world.
After accepting the offer, I spent about three months working remotely from France while my visa was being processed. That period was actually a great way to onboard gradually. I could start getting familiar with the codebase, the architecture, and the team before setting foot in Tokyo. Once the visa came through, I relocated and joined the team on-site.
What does an embedded engineer do at MUSE?
– What does your day-to-day work look like as an embedded engineer here?
I work on the low-level software that sits between the physical hardware and the higher-level robot application software. A large part of my work revolves around motor control, communication between subsystems, and sensor integration.
The high-level robot software handles things like path planning and obstacle avoidance, deciding where the robot should go. But those decisions are ultimately translated into motor commands, and that is where the embedded layer comes in. I work on the firmware that receives those commands and controls the motors, making sure the robot moves precisely, smoothly, and above all, safely. There is something satisfying about working on the part of the system where software becomes physical movement.
What makes this role particularly interesting at MUSE is that I am involved in the ECU software but I also work on parts of the robot software, which gives me a clear understanding of the full system.
– You mentioned safety. How central is it to your work?
It is the most important aspect. The high-level software can compute the perfect trajectory, but at the end of the day, it is the firmware that physically moves the robot. If there is a bug or a failure at the embedded level, the robot does not just display an error message. It moves incorrectly. In a supermarket full of shoppers, families, and children, that is not acceptable. A motor that does not stop when it should, or that accelerates unexpectedly, is a direct physical safety risk.
This is why the embedded layer has to be designed with safety as its first principle, not as something layered on top. Concretely, this means we design fail-safe behaviors so that if communication between the robot software and the firmware is lost, the motors default to a controlled stop rather than continuing their last command. The firmware enforces physical limits that cannot be overridden from above.
The way I think about it is this: the robot software decides what the robot should do, but the embedded software is the last line of defense that ensures the robot does it safely, or stops entirely if something goes wrong.
Gemba testing: bringing robots to the real world
– At MUSE, the word gemba comes up often. Can you explain what it means and why it matters so much?
Gemba is a Japanese term that literally means "the actual place." In manufacturing and engineering culture in Japan, it refers to going to where the work actually happens. In our case, the stores where our robots operate. The idea is simple: you cannot fully understand a problem from your desk.
The global service robot market is projected to more than double by 2030, surpassing $100 billion [1]. But the gap between a robot that works in a demo and one that works reliably in a real store every day is where most of the hard engineering lives. This is especially true for retail robots. At MUSE, we have a small store replica in the office for testing. But even with that, it cannot replicate the full complexity of a real store. A store is a lively, always changing environment, and that is what makes it so challenging for a robot compared to the controlled conditions of an office. From the embedded side, the differences are very concrete.
The most obvious one is the presence of customers. In our store replica, the robot moves through a controlled space. In a real store, there are people everywhere, walking unpredictably, stopping in front of the robot, placing carts in its path. The first time I watched our robot navigate a busy store during peak hours, I realized how different the real world feels compared to anything we can set up in the office. The robot's behavior has to remain safe and smooth in all of those situations, and that puts real pressure on the motor control and sensor systems.
Beyond that, the physical conditions of a real store (the distances traveled, the variety of floor surfaces, the environmental factors) all create situations that simply cannot be fully replicated in-house. Systems that perform perfectly in controlled testing encounter edge cases in real operation that only become visible over extended use. That gap between office and store is exactly what gemba testing is designed to close. It is also the best way to get direct feedback from store staff, understand how they actually use the product, and identify what we can improve to make it work better for them.
There is also a less technical reason I enjoy gemba visits. MUSE provides a monthly snack allowance for the team, and there is always a good feeling when someone comes back from a store visit with snacks for everyone.
– How does MUSE approach gemba testing in practice?
We conduct regular on-site testing sessions at partner stores. These sessions allow us to validate that the robot is performing as expected under real conditions, and give us fast feedback when we introduce changes. Rather than developing in isolation and hoping everything works in the field, we maintain a tight loop between the office and the store.
From the embedded side, my focus during these sessions is on monitoring real-time system behavior: confirming that existing systems remain stable and reliable, observing how the motors and sensors respond to conditions we cannot fully reproduce in our store replica, and identifying edge cases. It can be humbling. You spend a week on something in the office and then a shopping cart in aisle three reveals a case you never thought of.
When you observe something unexpected in the store, you bring that knowledge back to the office, reproduce the conditions as closely as possible, fix the issue, and validate the fix on-site in a subsequent session. It is a cycle that makes the product better in ways that pure simulation never could.
I think this approach is one of MUSE's real strengths. It keeps development grounded in reality and ensures we are solving actual problems, not hypothetical ones.
Bringing robots to society, together with members from all over the world
Working in Japan as a French engineer, in a team with people from all over the world, is a unique experience. What keeps me motivated is that the product is not finished. Every gemba visit reveals something new, every store is different, and the robot keeps getting better because of it. MUSE is working to make robots a natural presence in everyday retail, and I am proud to contribute to that mission. I look forward to what we build together next.
Reference
GlobalData, Global Robotics Market to Reach $205.5 Billion by 2030
Contact us
If you are interested in exploring how MUSE’s store robots could support operations at your Gemba (retail site), please feel free to contact us through the link below:
We’re growing our team. MUSE is currently hiring for a variety of positions across engineering, business, and corporate fields.
If our vision excites you, and you’re interested in the challenge of creating the future from scratch, we’d love to hear from you. Casual meetings and office tours are always welcome!
For job posting and application:
Looking forward to talking to you!
