I was curious whether anyone had any measurements of this.
Thanks
Do you mean power consumption / output or computational power?
Computational.
Would there be code doing simple test of “robotic responsiveness” that could be tried on a
RPi 3 housed BrickPi (I’m awaiting delivery of my BrickPi), that I could get working on my EV3?
Here are some generic specs for each:
#Pi3
SoC: Broadcom BCM2837
CPU: 4Ă— ARM Cortex-A53, 1.2GHz
GPU: Broadcom VideoCore IV
RAM: 1GB LPDDR2 (900 MHz)
#EV3
SoC: ARM9-based Sitara AM1808
CPU: 1x ARM9, 300MHz
GPU: n/a
RAM: 64 Mb
I’m not sure anyone has run benchmarks on both, but I’m sure people would love it if you did!
Here’s a link to some benchmarks folks have run on EV3:
http://www.mindstormsforum.de/viewtopic.php?t=8095
You could run the same on a Pi3, but that wouldn’t take into account all four cores.
I have a wheeled robot based on an EV3. I will be converting it to an RPi 3/BrickPi shortly.
I thought it would be interesting to compare timings for a performance limited robotic operation
between the two platforms, but couldn’t think of anything that would do the trick.
By the way, does the EV3 have anything like the BrickPi’s Arduino co-processor to offload its cpu’s
involvement in real time motor/sensor control?
Good question. I don’t know, but if you do come up with a benchmark, I’d love to read your results. We’re are just getting started with our EV3 & BrickPi, so maybe so.e day we can have them compete side by side.
Would a large number of small wheel turns do it?
#!/usr/bin/env python3
from ev3dev.auto import OUTPUT_A, OUTPUT_D, Motor
import time
iterations = 100
incre = 1
a = 0
motorLeft = Motor(OUTPUT_A)
motorRight = Motor(OUTPUT_D)
motors = [motorLeft, motorRight]
for motor in motors:
motor.reset()
for i in range(iterations):
positionLeft = motorLeft.position_sp
positionRight = motorRight.position_sp
motorLeft.run_to_rel_pos(duty_cycle_sp = 100, position_sp = positionLeft + incre)
motorRight.run_to_rel_pos(duty_cycle_sp = 100, position_sp = positionLeft + incre)
while any(motor.state for motor in motors):
a += 1
This ran across a hardwood floor with fresh batteries for 100" over 3 trials. I’ll repeat the experiment when I get my BrickPi.
I sure could use some advice on making this test more revealing.
As was pointed out by the specs listed by donald-braman, the RPi3 has significantly more power and resources. Software running on the RPi has more memory and CPU speed available than a program running on the EV3. The RPi has the resources to do a lot more complicated tasks besides just basic robot control (run a full desktop interface, VNC, camera based vision, etc. etc.). However, that doesn’t make the RPi/BrickPi faster at hardware based tasks, e.g. setting the speed of a motor, or reading a sensor, since those things are limited by hardware communication speed.
For a good idea of computational power, I recommend running an algorithm that uses the CPU heavily.
The EV3 main chip handles the motors and sensors, except for a 16-channel ADC for reading analog sensors (and some other internal analog signals). It does not offload those functions to a separate micro-controller like the NXT and BrickPi.
I haven’t run a benchmark comparing EV3 to Raspi3, but i have run benchmarks comparing Pi1, Pi2B and Pi3. From my own experience trying to do computer vision and AI stuff, Pi3 is finally fast enough to do computer vision, whereas Pi 1 and EV3 aren’t even close. The only thing Raspi needs is USB 3 to increase the bandwidth for Wifi. Right now the CPU is fast enough to handle 640x480 images at 26fps doing simple computer vision, but USB2 can’t handle the bandwidth. To get around that, I have to decrease the images to 320x240. Hope that helps.