Antoine Van Malleghem

The through-line

Across these posts, Antoine Van Malleghem keeps returning to one idea: robotics success is decided by how disciplined you are about hardware choices, and how honest you are about the unglamorous work that follows. Early in the period covered here, his posts are dominated by hardware validation, PCB testing, and vendor risk [5][10][11][13]. As iXi's hardware stabilizes, his attention visibly shifts toward software and the "last 20%" of features, troubleshooting tools, and environmental edge cases like sun glare [15][4][3][2]. Throughout, he insists that the product has to be genuinely different, not merely AI-branded, and that the team's pace toward production is the real measure of progress [6][14][7].

On hardware mastery

Van Malleghem treats hardware decisions as irreversible bets: "When hardware is shipped, it's costly to recall - SO choose it wisely!" and "Master every hardware component of your robot. Don't let luck decide your future. Mastery is key in the hardware world." [5] This is not abstract advice; it comes from direct experience debugging a magnetometer fault caused by motor noise traveling through the trolley's own frame, a problem he summarizes as "Keep your I2C communication on your PCB. Or learn it the hard way." [11] He applies the same rigor to new PCB revisions, describing test cycles that cover "NVMe read and write speeds, USB device speeds, CAN testing, RTC, and much more," and framing the engineer's job at that stage as one "where you can trust nothing and just validate everything." [13]

On hardware agnosticism and vendor risk

He is wary of over-committing to any single vendor's ecosystem. Reacting to a Jetson price hike of "between 33% and 101%" with no explanation, he warns readers to "avoid being too tied to a given piece of hardware" and to "think twice... before using a proprietary SDK that only works with certain hardware," adding pointedly, "Why do you think hardware companies provide free software?" [10] The same instinct shows up when a new Jetson Orin Nano is announced: he is curious about the specs but flags that "Same form factor doesn't mean it fits electrically," refusing to assume compatibility without testing [1].

On the last 20%

Van Malleghem has a stated preference for the grinding, unglamorous phase of engineering. Citing "a common software corollary of the Pareto Principle... you need 20% of the effort to create 80% of a feature, and 80% of the effort to create the last 20%," he says of iXi's current phase, "that's definitely the phase I prefer," even while admitting "a lot of frustration" and "fewer 'wow' effects" [15]. His troubleshooting approach favors data over generative tools: "PlotJuggler > Claude Code at troubleshooting things. Because yes, troubleshooting robots by looking at data is easier" [4]. He describes the current sun-glare problem the same way, as a "pragmatic" engineering challenge rather than a crisis: "now what we need is to be pragmatic. The current challenge is to deal with the sun" [3].

On product uniqueness

He is skeptical of AI as a marketing label. "Having AI in the name of a product doesn't make it smarter," he writes, adding that when people claim "this kind of trolley already exists," his own market analysis shows "there is nothing even comparable" [6]. This conviction underlies his framing of Botronics' mission as building something that goes "way beyond the prototype stage" and that will "revolutionize the world of golf" [14].

From the stage

In the 22Astronauts podcast, Van Malleghem gives context the written posts do not: his path started in software and AI work at large companies before he moved into robotics four to five years ago [17]. He also draws a personal distinction between being independent and being an entrepreneur, tracing his own entrepreneurial mindset to watching his father work independently with wood, in contrast to his mother's role as a bank employee [17].

Takeaways

• Before adopting a piece of embedded hardware, verify electrical fit even when the form factor is advertised as unchanged [1].
• Keep noise-sensitive buses like I2C on-PCB; long cables and even the chassis frame itself can introduce motor noise faults [11].
• Treat proprietary SDKs and single-vendor SOMs as lock-in risk, especially after unexplained price hikes like NVIDIA's 33-101% Jetson increase [10].
• Use data-inspection tools like PlotJuggler as a primary troubleshooting method for robotics issues [4].
• Expect the "last 20%" of a feature, the unhappy-path and edge-case work, to take four times the effort of the initial version, and plan resourcing accordingly [15].
• Don't equate "AI" branding with product differentiation; validate uniqueness through continuous market analysis instead [6].