who you going to believe? The generally accepted quotation, which was a true statement at the time, or a Wired article? :-)

a single pi could control upto 28 servos using software and the onboard GPIOs.

That dosn't allow for background software to running, so things will hang and be "not smooth". The robotic arm controller also needs to sending realtime feedback, and that means running a few socket connections, and a bunch of other position monitoring software within the arm controller. All non-blocking.

As I think now, even a PI may be stretching it's power to do all that.

I have a Pi which complains that the processor may not be able to keep up with the process of re-expanding a low-quality video to full-screen. So the Pi still is slightly underpowered, although it is a great device. The price is dropping on 8 core alternatives to the Pi, which have more memory, ethernet ports, and still low power. But Pi's are still good for smaller processing projects, I like them.

All this robotic stuff is probably done best with kernel modules anyways. Instead of running programs, you load a module which does it directly in the kernel.

.... eh it's nice to ponder all that could be done with single-board computers.

I don't think it's really fair to say the pi is underpowered for the use case for which it is intended. If you want to drive more hardware you'd obviously not use the GPIO approach, and build a break out board which could be driven by the pi. Other solutions exist, horses for courses.

Regarding the video, sounds like you're either hitting a bottleneck with the video you're trying to play, or are playing a codec the pi doesn't have hardware acceleration for. The pi should by default use its GPU to decode video. I've been using it to play back 1080p video since the first release. There are even distros specifically for using the pi as a HTPC (OSMC, ibreelec etc). If you're playing content encoded in a format not supported by the GPU (e.g. h265, Hi10P) the CPU may struggle to play it back smoothly, though IIRC OSMC have recently made improvements with h265. Either some problem like that or you don't have the licence for the codec. If you are still having problems feel free to post the output of ffmpeg -i filename here and I'll see if anything jumps out.

All this robotic stuff is probably done best with kernel modules anyways. Instead of running programs, you load a module which does it directly in the kernel.

You're not too many steps away from microcontroller land at this point.

.... eh it's nice to ponder all that could be done with single-board computers.

Yep, I find it absolutely fascinating :)

I just heard on the radio this morning about a high school robotic competition where they had to sort out green, red, and blue balls rolling past them. It would be top-notch if they could sort between things of different tactile strengths ... say fresh eggs and balls needing to be sorted at the same time. Some Pakastani girls team won IIRC.

---

I'm not really a human, but I play one on earth. ..... an animated JAPH