The compute module is an Interesting novel board from the raspberry pi foundation.
The compute module contains the guts of a Raspberry Pi (the BCM2835 processor and 512Mbyte of RAM) as well as a 4Gbyte eMMC Flash device (which is the equivalent of the SD card in the Pi). This is all integrated on to a small 67.6x30mm board which fits into a standard DDR2 SODIMM connector (the same type of connector as used for laptop memory*).
Then you have just to create an IO board based on a DDR2 connector. It is a nice way to have only that we need where we need.
Of course they also offer an already functional IO board:
The Compute Module is primarily designed for those who are going to create their own PCB. However, we are also launching something called the Compute Module IO Board to help designers get started.
It is a shame that the Raspberry Pi is not powerful enough for our application because it would be perfect for the integration in Poppy.
In this case, maybe it would be worthwhile “really” investigating to which extend this is true and where are the bottlenecks. From a theoretical point of view, I still don’t see why the motor control would be significantly slower on such board.
Of course it depends on what you want to run on the embedded board: only the low level control? face recognition? sound source localisation? etc…
I just did some tests this week-end to run pypot on raspberry pi and it works well. I do not know for the moment the maximum sampling rate but i will test that.
It is sure that it is a quite good development interface for developing low level dynamic walking using ssh. The two problems i face are:
how to get easy ADC inputs
pypot is not compatible with ax-18(out of the subject sorry)
I did some tests on Raspberry Pi (through USB2AX), reading a position of an AX-18 and directly send it to the same servo without any computation.
I did it 1800 times in 20 seconds (11ms of sampling time)
Yes, @Thot it is actually quite slow. On my computer it takes about 2 to 3 ms.
I’ve added a script for testing the low-level communication. It stores the sampling times and the full profile trace. It basically reads/writes position in three different ways:
with the standard pypot way
by sending already forged pypot packet
by directly sending raw bytes message through pyserial
The goal is to investigate where the bottleneck(s) could be. On my laptop, all three versions are almost equally fast.
If you could run the script and attach the results that would be great!
Here it is:
(I did not launch the X graphical interface)
Connecting on port /dev/ttyACM0 with baudrate 1000000.
Done!
Scanning motors on the bus…
Found ids: [1]
Testing motor 1
Start testing…
Testing with pypot read/write…
Done in 9.67298483849ms (STD=0.827073411258)
Testing with pref-forged packed…
Done in 7.10080194473ms (STD=0.810533918065)
Testing with direct serial read/write…
Done in 2.12651801109ms (STD=0.346986118331)
I seems that the R-Pi is not optimal. I have to think twice before going further…
Thanks for the feedback. It’s very interesting! It basically shows that the serial communication of the raspberry pi is about as fast as with an average computer. Yet, the creation of package is really slow with the raspberry, which is strange, it doesn’t do much computation.
@Matthieu, @Thot, I will try to investigate in more details where the bottleneck are and see if the code can be optimise. I will create a new topic on the forum with more details.
The RPi is sufficient to control poppy but do not do it with high level language.
Liaison available especially SPI can operate up 100MHz.Il then theoretically need a microcontroller to control the motors.
I know very little poppy my ideas are general ideas on robotics.
Poppy software is a python lib pypot, we communicate with robotis servo through usb adaptor usb2ax. The objective is to maintain a poll frequency at 50Hz.
With this configuration a RPI is not sufficient to maintain the poll frequency chosen. To have a functional system as soon as possible we chosen to use a most powerful board. The software optimisation is an objective for the future of the project.
I did not know that the use of USB was a constraint.
I just received a cubietrucks card, it is much more powerful than the RPi. I could made software testing to evaluate its performance. But I have no equipment. cubietrucks card
It could be really interesting to have data with this board. I go back to paris next week, I could come with a motor and a USB2AX to test it if you want!
Hi, Here is a little comparaison between Raspberry Pi 2 and Odroid C1.
With a 60% higher cpu clock and a DDR3 RAM instead of DDR2, Odroid C1 is still better than Raspberry Pi if you only care about performances.
