> The hardware is built around a stackable 10×10cm compute module with two ARM Cortex-A55 SBCs — one for ROS 2 navigation/EKF localisation, one dedicated to vision/YOLO inference — connected via a single ethernet cable.

I will preface this by saying that I have nothing against ARM per se, that my employer/team supported a good chunk of the work for making ROS 2 actually work on arm64, and that there is some good hardware out there.

I really don't understand why startups and research projects keep using weird ARM SBCs for their robots. The best of these SBCs is still vastly shittier in terms of software support and stability than any random Chinese Intel ADL-N box. The only reasons to use (weird) ARM SBCs in robots are that either (1) you are using a Jetson for Jetson things (i.e. Nvidia libraries), or (2) you have a product which requires serious cost optimization to be produced at a large scale. Otherwise you are just committing yourselves and your users/customers to a future of terrible-to-nonexistent support and adding significantly to the amount of work you need to bring up the new system and port existing tools to it.

▲

Sabrees 3 hours ago | parent | next [-]

If you can send me an open hardware Intel, or Jetson I'd happily use it.

Part of the point of this for me is to see what's possible with open hardware (down to chip level at least)

▲

cpgxiii 2 hours ago | parent | next [-]

There are a variety of x86 products with Coreboot support, if what you are looking for is firmware openness. If what you are looking for is PCB design openness, the options are much fewer, but at that point you are probably optimizing for an overly niche objective.

> Part of the point of this for me is to see what's possible with open hardware (down to chip level at least)

I appreciate the idea, but this is essentially saying "this project will prioritize a specific choice of one (core) piece of hardware to the detriment of everything else, users included". Approximately none of your potential users are going to benefit from the "openness" of the SBC versus that of a more broadly-supported platform (I say "openness" because the reality of SBCs is that actually finding a usefully performant one that is completely blob-free is almost impossible). Open hardware means very little if it isn't running an upstream kernel and userland.

	▲	Sabrees 2 hours ago \| parent [-]
		The software does explicitly support Jetson for example, and I'm sure the stack would run on Intel if you want it to. The Mainline kernel for this particular board is _almost_ there 6.20 or so I expect. Armbian support is good.

▲

Neywiny 2 hours ago | parent | prev [-]

Framework? Maybe?

	▲	Sabrees 2 hours ago \| parent [-]
		Framweork have done the best they can within the confines of Intel licensing, still a long way from being able to fabricate it though https://github.com/FrameworkComputer/Framework-Laptop-13/tre... In a few years we'll all be using more open RISCV stuff of course.

▲

schaefer 3 hours ago | parent | prev [-]

> The only reasons to use ARM SBCs in robots are...

Obviously, anyone can have there own opinion on this. I work in robotics, we are quite happy with our A53 and M4. Though, we use a SOM, not a SBC, if you feel like splitting hairs.

	▲	cpgxiii 2 hours ago \| parent [-]
		You probably aren't using some weird SOM, though. There is a bit of an unstated exception of "unless said SBC/SOM has specific hardware that is necessary/particularly valuable for your product/project". For example, if you need GMSL you are probably not going to be picking Intel, even though ADL-N and the bigger processors support MIPI, simply because no one else does and the documentation/support for it is basically nonexistent. Designs with closely-coupled A/M/R cores, or CPU/MCU/FPGA hybrids like Zynq would be others. But generally projects which are choosing some random SBC aren't using any of these features, and are just suffering the pain/imposing it on their users for no good reason.