Poppy 1.1 : Hipi

electronics
english
Tags: #<Tag:0x00007fc8ed2aaf90> #<Tag:0x00007fc8ed2aad10>

#1

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
  • Audio amplifier 3W stereo
  • A tiny IMU

[CFC] : Poppybox
Poppy Ergo with Raspberry Pi 3
Carte odroid XU4
Integration of a screen in the Poppy's head
Danse contemporaine - School of moon
Poppy 1.1 Carte mère: Raspoppyno
[CFC] Make a Creature with the Darwin Mini humanoid robot using a Raspberry Pi
How does odroid xu-4 connect with MX-28R?
Alimentation de la carte audio
#2

We start to design the Hipi board here

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.

We will continue investigations.


#3

Thanks, it is interesting. How do you measure CPU usage ?


#4

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).


#5

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.


#6

We use “htop” to do this.

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.


#7

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 :slight_smile:


#8

Yes absolutely! They could either go next to the raspberry-pi images (see https://github.com/poppy-project/poppy-ergo-jr/releases for instance) or you could make a dedicated repo explaining how the image was made.


#9

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).


#10

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.


#11

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…


#12

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.


Un espion dans poppy
#13

What is happening around t=80us? Why the signal is shifted only from that point onward?

Is that command making the motors move? or do we see before 80us a send command and after 80us a receive/respond from motors?


#14

Yes, the shifted 0 around t=80ms is the motor reply and before is the pixel transmit.

We don’t know exactly why we have this shift…


#15

Is this measure done with 10 mx-28 or 10 xl-320 ?

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


#16

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.

Yes that’s the problem!


[CFC] : Poppybox
#17

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…

I am refering to this private thread: https://forum.poppy-project.org/t/shield-poppy-1-1/1684/7


#18

Here is the new version :

Pixel.PDF (705.3 KB)


#19

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.

Does this makes any sense?


#20

Why not using two SN74LV1T126DBVR, one for TX and one for RX?

Anyway, this might not even be the problem because the transmission seems to works fine.