robot?
just to walk and alot of sensores =arduino
walk and have camera = bbb
wifi ethernet = bbb or arduino
like linux=bbb
like c =arduino
small = ardunio
need mor information
…
Some things you might not want to waste ARM resources on, and an AVR based board could handle those tasks and talk to the ARM.
I can see uses for both at the same time in a robotics project.
-david
You could also have an MSP430, Any number of Cortex M0+ ( or even M4 ) MCU’s, PIC, 8051, Paralax propeller . . .to do some of the leg work then talking to a BBB. The list is only really limited to the number of MCU’s capable of interfacing with a BBB via I2C, SPI, or UART. There are even some hybrids that act as sort of a USB<->SPI / I2C / UART bridge.
Anyway, like what has been posted already. Need more information. As in you need to know what your system is going to, and even then you could potentially get 50 answers.
I have used BBB, RPi, and arduino.
arduino is closer to real-time if you need that. However, it does only what is programmed in C in a loop fashion. There is a setup() function and loop() function.
just about everything is done in the loop. If you need tight integration (real-time) with some piece of hardware, then arduino is the way to go.
BBB and RPi, are linux computers. BBB outclasses the RPi in the number and kind of GPIOs, I2C, etc. RPi has no analog in/outs. BBB does.
However, I think the RPi has better HDMI capability.
Both the RPi and BBB are linux, so you get the capability to multi-task with separate processes doing something/communicating with each other. You can write your code in almost any language you can imagine. I prefer python, but there are a choice of many others. With arduino you get their version of C - thats it. But with all the greatness of linux, comes the con: Linux is not realtime.
It really depends upon what you want to do. But you don’t have to settle for just an either/or situation either. You can do dedicated real-time input/output with the arduino, and pass that along to the BBB to decide how to react.
Unless you use the "pru" on the bbb.. 
Regards,
The term real time is subjective in this context anyhow. There is always going to be latency, it is just a matter of how much you can put up with. After all we’re not talking about some medical device, or Automobile control system. UAV ?
But looking at this from an automobile perspective, you have a main computer system with many MCU’s Performing sometimes critical tasks, and communicating back and forth with this main system via CANBus.
The OP really needs to define “Robot” more clearly. I mean we’re not talking about an AT-AT walker model with stepper motors, while also having the ability to walk around are we ? . . .
I really haven’t done any serious real-time since my DEC days.
I was a software specialist for DEC in Dallas, who specialized in real-time apps for RT-11 and RSX.
At that time I was handling in excess of 3000 interrupts per second in assembler on a downloadable RSX-11S image.
This was on old hardware by today’s standards, I would think.
For real-time what is expected interrupt rate on an ARM? BBB specifically?
I really haven’t done any serious real-time since my DEC days.
I was a software specialist for DEC in Dallas, who specialized in real-time apps for RT-11 and RSX.
At that time I was handling in excess of 3000 interrupts per second in assembler on a downloadable RSX-11S image.
This was on old hardware by today’s standards, I would think.For real-time what is expected interrupt rate on an ARM? BBB specifically?
If you are talking Linux events and not interrupts, then you are probably (without me bothering to check or look things up) in the hundreds of microseconds or a millisecond. If you write a kernel driver to handle the interrupt as you should on a Linux system, then you are talking likely a few microseconds as the A8 pipeline is a dozen clocks deep and the context save/restore is fairly burdensome. If you are talking PRUs, it only polls interrupt sources and depends entirely on the inner loop. http://beaglelogic.net is sampling 14 pins and saving over 1GBytes of data at 100MHz, so the PRUs can be dedicated to functions and handle interfaces with extremely low latency typically in the hundreds of nanoseconds based on your event loop.
From what I understand the PRU’s( there are two ) operate at 200Mhz, and run independently from the main processor. Most instructions also from what I understand take one cycle, and a cycle being 5uS ( someone correct me here if I am wrong ).
The main processor on the other hand, running Linux we’re to expect latency in the millisecond range. Fast enough for many things but not fast enough for high speed / resolution PWM / ADC etc. It is my understanding that running a real time kernel would tighten things up, perhaps a lot.
Assuming we may think running Linux is beneficial ( and it really can be ) we can use something like an SBC to handle much of the work that does not require very low latency. While the tasks that do require very low latency we can either use 1-2 PRU’s, OR use external MCU specific to the task at hand, that stay in communication ( somehow ) with the main board. This main board can then be used as a communication / control hub internal to the project, and to the outside world.
Personally, I struggle with the idea of using Linux myself in several embedded situations. As in “why do i need to add this complexity”, etc. Surely you could use some development board, or processor tied to a wireless device with an embedded networking stack. But then you price such devices, and you realize that you can very easily double, or triple the costs of the BBB. While the BBB being a Linux computer, if you need wifi, you buy a $12-$15 USD wifi<->USB dongle, making sure the chipset you chose has good support in your distro of choice. OR since the BBB also has UART, and SPI, you could also use a wireless device as mentioned above. But again, you’re going to double your costs.
Passed this, the BBB having the ability to run Linux and thusly being far more general purpose. It can be used in far more situations.
Anyway this is just my own thoughts on this topic, and surely there is more to consider than the tiny bit I covered.
From what I understand the PRU’s( there are two ) operate at 200Mhz, and run independently from the main processor. Most instructions also from what I understand take one cycle, and a cycle being 5uS ( someone correct me here if I am wrong ).
5ns