Odroid Board used for poppy humanoid (U3) disappearing some month ago, so we switch to a new odroid version (XU4). This board is excessively powerful but there is no sound interfaces and a really dirty integration into the head of poppy humanoid.
We choose to switch to RaspberryPi but USB2AX need to be mount out of the head on the usb ports. We started to redesign a new RaspberryPi based on compute module called Raspopyno, but it is relatively expensive and there is only the RaspberryPi 1 version available. You can find this work described here and a topic related to here :
After many reflexion and hesitations we abandon this project because it is a really complex and overkill one!
For Poppy ergo Jr we use RasperryPi 2 with a board called Pixl. This board manage power conversion and communication adaptation, so we should use this for poppy humanoid instead of USB2AX!
This board will be named Hipi and it contain :
A power conversion part 12V/5V@3A
2 x āFull duplex 3.3Vā/āhalf duplex 5Vā converters
We also start to try RaspberiPi 2 on Humanoid robots.
First we try RPI with 2 USB2AX and movements are really jerky! This problem could be due to the CPU occupation, we measure 25% of CPU usage, or it could be due to the usb bus saturation! Raspberry only have 1 real USB divided on 4 ports and 1 Ethernetā¦
So, we choose to try the same thing on a torso (with only 1 USB2AX). Movement are better, but why? We measure again the CPU usage and we have the same value of 25%. The problem could really be the USB saturation! to confirmā¦
After that we start test with a Pixel board. First we try to detect all motors on a torso, but we have many communication problem. After small investigation we have impedance trouble when we have a lot of motor, commutation time of the signal is really too slow. We change a pull up resistor to boost the signal current and decrease the switch time (we change the default 500homs output pull-up to a 200homs). Now we have a pretty clean signal and we can detect all motors except AX12ā¦ But we donāt know why at the moment.
If RPi has only 1 ārealā USB port then do you think using two USB2AX gives any benefit? And in fact, since RPi has Rx,Tx pins exposed, the use of USB2AX is redundant (also it increases the cost).
In term of CPU performance & bus bandwidth Odroid XU4 is much powerful than any RPI, for audio there is the I2S link on the bus that can still be used. It is a pity to drop it entirely.
Yes, because of impedance. A lot of motors on the same line decrease impedance and create many distortion on the signal line.
In deed Odroid is really much powerful, but users are not as comfortable with a RPI. A non linuxian guy will find everything he dream on the web! Thatās why we choose RPI instead of Odroid.
I also use several RPI because they are cheap and the linux distribution is always up to date with the latest kernel which is incredible and you can do much more than with a microcontroller but if you want USB bandwith and CPUā¦Iāve never seen an embedded platform as fast as the ODROID XU3/4ā¦
Maybe we could maintain an ubuntu image for XU3/4 so that people could just flash it. Where could we store it to share it?
There is a the cheap CHIP : http://getchip.com/pages/chip which can now debian distribution for $9ā¦ why still use microcontrollers
Yes absolutely! They could either go next to the raspberry-pi images (see Releases Ā· poppy-project/poppy-ergo-jr Ā· GitHub for instance) or you could make a dedicated repo explaining how the image was made.
We planned to add iso images on release for every creatures. We intended to make it automatically with a chroot on qemu but we had some issues (impossible to do it with travis-ci, qemu tricky issues, ā¦) and didnāt take much time on it. It would be a great contribution to maintain it !
You can send us the iso images, or we can also add you in the GitHub poppy-project team to have a write access (you canāt make pull request on releases).
I can share and maintain my Odroid xu3/4 image but I only use poppy-humanoid (I wonāt know and even be able to maintain all the creatures).
In fact I was thinking about sharing an iso image and the a PPA repository so that it would be more ubuntu compliant and less space consumingā¦ So I think the cleanest way for Odroid is maybe to share PPA and explain how to do it, so that people having other creature could derive from it. Iāll dig into that approach and keep you posted.
I was also thinking about a good way to automate tests and I agree qemu is great but has limitations. In 2005, I bought an osciloscope from bitscope, I donāt know if you are familiar with them but they are great (at least for hobbists) and not too expensive. I noticed that they now have a product to put RPI into clusters, http://www.bitscope.com/product/blade/?p=index. It wonāt solve the Odroid case but it could be a cheap way to build a RPI CI.
Be careful to allow people to easily know what version they have or donāt do too much versions, as you will have hard time debugging anything (remotely, by forum, with someone who is not an expert) if everyone uses a different versionā¦
We continue investigations auround the usage of a raspberry pi on an humanoid robot
We benchmark the quality of a given signal with 13 MX28. EDIT (@juju) : this is mesured on the the data pin of the last motor of the chain (assumed to be the worse case).
The First part of the signal is the command (a ping here), the second part (after 80Āµs) is the answer of a motor.
On the output of the Raspberry Pi, this is shifted to 3.3 level logic, but with a similar signal.
We assume it is a an issue of the level shifter of the pixl.
USB2Dynamixel :
USB2AX :
Pixl :
We donāt know exactly why but we have a clear signal shift on Pixl probably due to the 3.3v to 5V convertion.
Maybe you can make a second measure before the pixl board, just at the output of the motors to check what happened without the shifted level of the pixl.
In fact, Iām not sure to understand on what side of the pixl you put your oscilloscope ? And with USB the TTL signal is at 0V / +5V, isnāt it ? (and on the picture I see 3,44V, is it the scale) ?
Iām thinking the same time Iām writingā¦ Am I right if I say that there is about a +0.8V gap when the Pixl is in reception of the signal from the motors and it is not normal, the pixl should be at 0V
This measure has been done on a torso robot without AX motors, it is only 13 MX28 motors. The measure point was directly on a motor. But the measure after the Pixl is the same. the raspberrypi send 3.3v signals.
That is a problem for sure, but the threshold to decide if it is 0 or 1 should be way above that? Are you sure this is the real problem?
Anyway, trying random thoughts too:
0.7 makes you think of a diode somewhere on the way, maybe in the pixl? Or maybe the impedance at the RX input of the RPI is too low such that R5 is impacting the voltage seenā¦
I am really rusty at this game but it might still make you think of somethingā¦
OK I brainstormed with a friend here. Here is what came out:
When Tx is 0, gate of T3 is pulled up by R6, and drives DATA to GND. But T3 gate is pulled up at 3.3V while driving a line at 5V. The gate should be driven high by a VCC rather than 3.3V.
If this is done then T2 runs into the same problem, driving with Tx at 3.3V while driving stuff at 5V. So Tx needs to be shifted too from 3.3V to 5V.
