I'd be curious if anyone has found an issue with Mac reliability. My experience is just the opposite. I power off my Macs maybe once every 3 years or so. Excluding the infamous butterfly keyboard problem, I haven’t had a hardware issue with a Mac in decades. That has not been my experience with PC hardware. I’ve spent quite a bit of money replacing failed components there. Usually about $1,000/yr to keep Sigyn happily chugging along. As for the AI’s rant, it probably helps to remember that any PC is not a replacement for an embedded system, but then, that’s never been an issue with me. When I need things like GPIO, the Raspberry Pi is almost never the answer for me. Well, not in any robot use.
No native GPIO? Correct, like all PCs. But there are dongles to deal with some of those issues. I use an MCU for those needs. It’s easy to talk to an MCU from a PC. MCUs are really cheap and easily powered.
No kernel patching? What? I get constant patches to my Apple devices. They are highly secure (relatively). That, of course, is the opposite of non-Apple phones, but that’s irrelevant here.
Driver model is closed? Unlike what, NVIDIA drivers? Again, on a PC, that hasn’t been an issue for me. I used to write drivers, it’s a full-time job, not for a single person. They aren’t a thousand lines of code anymore. What driver would you like open-sourced?
USB stack not optimized for robotics hardware? I’ll bite, how so? What example is there where it makes a difference?
The bottleneck is hardware interfacing? Well, sort of. My PC in Sigyn just uses USB for everything. There are multiple USB busses, and they are all really fast, much faster than my needs. I do have to remember to partition video streams to different busses. But, again, trying to drive GPIO on a Linux device is its own kind of hell once you have to care about not getting your eye shot out with a BB gun—when you need predictability and reliability. Well, in my experience. I haven’t used real-time Linux. I have used the high-priority scheduling for my local planner. It’s a lot better than non-high-priority scheduling, but I wear BB-proof glasses when my robot roams the house.
I worked for a time on very high-speed communication for the New York Stock Exchange. I sort of know what can be done in Linux if you want to make the effort, but I’d be surprised to find a handful of people in the club that know how to do it. I’m aware of many of the things you can do, but I do pretty much none of them. The critical stuff I put on something where I can control the timing. Otherwise, I rely on the fact that computers are blisteringly fast, if you don’t mind scheduling variation.
OSes, to me, are kind of like C++, and I use to write C++ compilers, code optimizers, etc. C++ is, in my opinion, one of the worst, popular languages of all time <very long rant omitted>. Because I don’t have a better answer for my coding needs, I just avoid using all of the bad parts of the language. Linux is not the best OS you could make for robotics. I try to avoid all the bad parts.
I’d like to say that I’ll take AI’s word that the Mac doesn’t provide any of "that level of control” (from the AI rant), but I won’t. If I need it, I have friends at Apple that could tell me if the control is there. I’ve been on the sidelines of discussions with hardware providers to Apple, and Apple has the usual mix of brilliant people and people who are less so. They keep the Unix base code chugging along, and they are aware that some users require top-tier performance. Remember, they were building autonomous vehicles as well. But, again, the PC is a different device.
Raspberry Pis are half an order of magnitude slower than a Mac Mini in the best, biased test you can do. Mac Minis are 10s of times faster in a lot of cases, as well. But Pis are quite a bit cheaper. Importantly, Pis, especially the power-hungry Pi 5, are “fast enough” for a lot of robot stuff, if you don’t push it.
Except for providing the 40-pin bus, I have a huge number of issues with my Pis, and I’ve used several dozen of them over the past decade in a fair number of inventions. Your mileage may vary. I do not recommend embedding a Mac Mini in a robot, mostly because it really wants to run the Mac OS instead of Linux, and you have to crack the case and bypass the power supply (usually). The real issue is that Apple, as a company, will just not play nice with the ROS folks. And the ROS folks will just not get over their addiction to x86 instruction sets.
I’d say my recommendation is that if your robot is simple enough, just use MCUs. There are quite a few ones with large RAM and impressive clock speeds. My favorite is the Teensy 4.1 because it was unmatched at the time and I’ve invested a lot of time learning how to use it. But I’m looking into some of the new ESP32 chips now. I might be using one of the Pi devices as I spin up a specialized April Tags recognizer to help me mate my robot with a charger. (I have an interesting other April Tags-based project I just started last night. Shh!)
The next step is to use the popular Raspberry Pis. I like the Pi 5, but it does have a battery addiction. My problem with the Pi is, as discussed above, determinism and latency. If you’re going to use ROS, well, it may be inherent in the algorithms even beyond ROS, a lot of the software depends on high frame rates from the sensors, having time stamps that are close together for all of the sensor data, and making sure that sensor latency and compute power deliver control results quickly and with low lag. When you’re driving at slow speed, with a lightweight robot, and there is no penalty or liability for the robot smacking into things or failing to be able to move all of a sudden, you may never need to go beyond what a Pi will provide.
Me? I need to know that I can trust my robot. Eventually, my life may depend on it, since Sigyn is intended to be my personal assistant as I age. It must no knock my medicine off from a side table to the floor because it couldn’t detect thin legs on a table that wasn’t there an hour ago. It can’t get the wheels tangled up in power cords. It can’t delocalize and stop when I need my heart medicine. Tackling those issues has been a bitch. But it’s a reason that I get up every morning and prepare to have a day of shouting at the AI that is helping me to code.
Oh, on a bright side. I just used Claude Sonnet 4.6 last night. What an improvement! No shouting at all as I did a fairly complicated bit of programming.
Always keep in mind before you pay attention to any of this, that I’m 75 years old. I know an awful lot of stuff. Almost half of which is probably actually true.
This is a great subject, though. What is your experience? Tell me a story.