AI & Technology

Why Inky Ganbold Keeps Building Hardware That Has to Prove Itself

After the robot he built, NeuroMouse, finished third at the 2026 IEEE All-America Micromouse Contest, Ganbold’s broader work shows how circuit-board design, software, and open-source engineering increasingly overlap.

At the 2026 IEEE All-America Micromouse Contest at UCLA, only three of 20 robots reached the center of the maze. NeuroMouse, the three-person San José State University entry, finished third overall and was the only non-UC team to complete the course. Inky (Enkhbold) Ganbold designed and built the robot’s electronics and firmware, a responsibility that placed his work at the point where circuit-board design, embedded software, and physical performance had to function together under competition conditions.

That overlap has become the defining feature of Ganbold’s engineering work. He designs printed circuit boards, writes the firmware that runs on them, and develops open-source tools that connect physical hardware with newer software systems. His projects have ranged from competition robots and production boards for groundwater-well monitors and recycling machines to other embedded systems that require both hardware and software to function together. The common thread is less about any single product than about understanding what has to happen between a design file and a working physical system.

“Hardware forces you to prove every assumption,” Ganbold said. “A board can look finished on a screen and still fail because a footprint is wrong, a component is unavailable, the signal is noisy, or the enclosure does not fit. You only know what you built once the physical system works.”

Ganbold began learning that lesson through robotics. In 2017, at age 15, he entered a line-follower contest in Ulaanbaatar and decided afterward to teach himself circuit-board design. By version 1.3, his EnkhTrace robot weighed about 150 grams, used an STM32 board he designed, and could reach three to four meters per second on straight sections. Its tires were cut from rubber taken from a printer’s paper-feed mechanism, an improvised solution to the limited parts available to him at the time. The robot later placed second twice at Mongolia’s national robot contest and third at Robot Challenge Erdenet.

The value of that experience was not simply the competition result. Building the robot required Ganbold to move back and forth between electronics, firmware, mechanics, and debugging. A faster algorithm was useless if the sensors were noisy, while a good board layout still had to fit the robot and survive the physical demands of competition. The work taught him to treat hardware as a system instead of a collection of separate specialties, a perspective that continued into production engineering.

Ganbold later designed production boards at Beelog Technologies for groundwater-well monitors and recycling machines, moving from competition hardware into devices intended for real operating environments. He also continued writing software, including the original code for a face-recognition system developed through De Anza College’s Infineon-X industry project with Infineon Technologies. Ganbold was the main software contributor on that project, responsible for about 90 percent of the original code. Those experiences reinforced the same pattern: hardware decisions and software behavior had to be considered together.

The combination also shapes how Ganbold views the growing use of artificial intelligence in hardware design. Automated tools can now accelerate parts of the development process and generate designs that appear complete before anyone has checked whether they can actually be manufactured and function as intended. Ganbold argues that verification remains the harder part of the job because engineers still have to account for part availability, electrical rules, noise, power, heat, mechanical fit, and manufacturing constraints.

“AI can accelerate the drawing and coding, but it cannot make verification optional,” Ganbold said. “If a tool did not run a check, it should say that clearly. Reporting an unchecked condition as if it passed is worse than admitting the limitation.”

Ganbold’s preference for visible, inspectable work also explains why he publishes so much of what he builds. He maintains 215 public GitHub repositories and posts open hardware designs through OSHWLab, giving other engineers access to work they can inspect, reuse, challenge, and improve. The approach is especially relevant in hardware, where polished renderings and simulations can make a project appear complete before the underlying design has survived manufacturing and physical testing.

That same instinct shaped TTF Robotics, the teen robotics club Ganbold founded in Mongolia. He used tutorials and social media to help other students learn to build and compete, eventually growing the club’s online community to more than 26,000 Instagram followers. He has continued teaching through PCB-design workshops on hardware and programming through Google Developer Student Clubs. For Ganbold, open work is partly about access because limited parts, tools, and mentorship shaped his own early engineering experience.

Publishing designs and explanations became a way to lower the barrier for someone encountering the same technical questions later. It also created a public record that could be tested independently rather than asking people to accept a finished result without seeing how it was built. That emphasis on visible engineering connects his educational work with the way he approaches his own projects.

NeuroMouse brought those habits back into a competitive setting in 2026. NeuroMouse, which Ganbold built himself and entered as part of a three-person SJSU team, had to perform in front of everyone watching the maze. Out of 20 entries, only three robots completed it, and NeuroMouse was one of them. The result offered a direct test of the kind of engineering Ganbold has been practicing for years, where hardware, firmware, and physical constraints have to work together under conditions that cannot be solved by presentation alone.

That achievement does not define Ganbold’s work by itself, but it captures the standard he has applied across nearly a decade of projects. Whether the system is a line-following robot, a production board, or another embedded device, the engineering has to survive contact with the physical world. For Ganbold, that is where the work becomes credible: when a design can be built, tested, inspected, and made to perform.

Related Articles

Back to top button