Poppy and live Motion Capture


#1

We have been experimenting with the Poppy Humanoid for use in performances, mainly dance. Here is some testing of Poppy using live motion capture data from a human to create motion.

Still a few issues like power spikes if we switch the data on and the poppy has to jump too fast to the start position (sometimes causes reboot in Odroid XU4). Will have to ease the start in.
Also the motors can heat up pretty quick in some positions.


#2

I saw some of your videos, I like the way you use Poppy. I see you use ODROID XU4, did you have any issue with trembling movements with XU4 ? Did you solve this issue ? If yes, I am very interested.
Concerning the motion capture system, is it a system with IMU ?
For the ODROID reboot, I advise you to have a separate power supply (with batterie) for the computer. It is really great.

great job :slight_smile:


#3

Thanks Thot. Great idea about separate power supply for the XU4. I already use batteries in the thighs like you suggested in another post.
yes, we had a lot of bad trembling with the XU4 originally. no matter if we drove the motors direct or recorded motion. But I just downloaded and flashed the latest image and it is much better. So we can’t take credit for the improvements.
It’s still not as smooth as some other small humanoids we have but reasonably acceptable I feel. Much better than before.
The mocap system in the video is a perception neuron IMU system.
We also run it with optical mocap systems.
Overheating is an issue still with mocap as the motors don’t get much rest, and can get into loaded positions.


#4

The overheating problem is something you get used to. You will see there are some more cumfortable positions with respect to heat.
For most of Poppy I manipultated, the neck gets easily hot. When I do not use the head, I often make it compliant.
The knees are also heating a lot. Most of time, I use the robot kneeling and I set the knee motors compliants, sitting on the mechanical stop.

Thanks for the XU4 tip, I will do this (I made an update which lost all, so I have nothing to loose)


#5

Great job !

Concerning the overheating problem, I often have the spinal column heating when Poppy is moving while standing.

@Thot, I succeed in making Poppy move smoothly. I am currently making all my modification clear to share it, and I will try to indicate what really matters to make the moves smooth.
As I already told you, the problem is that the XU4 is not as fast as the others, so we have to reduce the calculating time of each position.


#6

@damiend any suggestions for improving the smoothness of motion using XU4 would be great!
I’m surprised that it is slower. Do you know where the bottleneck is?
Cheers!


#7

For information, I decided to replace XU4 by Raspberry Pi 3 and all is OK now. I had also driver issues with XU4 (for wifi dongle). On Raspberry Pi 3, thanks to community, the drivers are already compiled…


#8

Do you have any smooth trouble with RPI3?


#9

@john Calculating is just slower with the XU4. The trick is to reduce calculating time.

To do that, I’ve done these following points :

  • added a cache in Pypot (this one has been integrated to Pypot (pull request of Philippe Capdepuy) )
  • control just the motors that needs to move in my program
  • using goto_position, choose dummy rather than minjerk

I have some other tricks for a complete move (several goto_position) but there is a bug when I try with the latest version of Pypot. When this problem will be solved, I’ll give you a full list of the useful modifications.


#10

with the MX-28, all is ok. I have issues with xl-320 but it is due to time out. I have to check the cables.
I have played several times with rpi3 and xu4, the main difference is the kernel version
xu4 is stayed at version 3.10 while rpi3 is at 4.4. But the odroid community has not yet switched to new kernel.

Considering computing time, I do not understand since xu4 is an octocore and rpi3 only a quadcore.
And even if it is a quadcore, polynomial interpolation shall not be a bottleneck.


#11

It seems that switching thread on a Odroid XU4 takes an insane amount of time. Pypot has quite a few. Yet, the behaviours observed on the Odroid are really hard to understand. This is the main reason we decided to switch to Raspberry-Pi where the computer power is not as good but the support is way better :slight_smile:


#12

To complete @thot and @Pierre answer, the issue is most likely due to time to lock and unlock mutex.

I used sysbench to benchmak an Odroid U3, an Odroid XU4, a Raspberry Pi 2 and 3, and my laptop. The mutex benchmark is the only one where the Odroid XU4 is far slower than the other computer boards.

All benchmarks results and commands are in this Jupyter notebook gist : http://nbviewer.jupyter.org/gist/show0k/6dba3a7f46270f88633d


#13

I’ve just finished making some tests on Pypot to make Poppy smooth, and here are my findings :
Added to the time problem @theo talked about, I think that there is a real problem with the XU4 with calculation time.

In my program, I use a primitive that is executed very quickly several times, and in which a goto_position is called for all the motors that must move.

  • When I use minjerk mode (long calculation time), the moves are not smooth at all.
  • When I use Dummy mode (short calculation time), the moves are smooth.

In the second case, it’s smooth, even if a lot of primitives are executed, so I think that the calculating time does really matter in the XU4 problem.

Moreover, I talked with @Thot, and he had the same problem : I suspect that in Fire, his position/trajectory calculations are too heavy and takes too much time for the syncloop in the XU4, but are okay in the RPi.

So I think that it’s important to take into consideration the calculation time when doing program with XU4.


#14

@damiend Thanks for the info! very useful.
I’ve been mainly using goal_position, I’ll try with goto_position and dummy and see if it is less jerky.


#15

To complete, the trick i use is to call a primitive with goto_position with a duration of 1.5*t, while the main calls the primitive with a period of T=t. That results in going to the different positions step by step in a smoothly way.

And you choose t to configure the speed of the movements.


#16

Has anyone tried Raspberry Pi 3 with poppy humanoid?
Just wondering if the movement is smoother.


#17

Yes, I did, comparing to odroid XU4, the movement is smoother.


#18

That’s really interesting.
I imagine you built from source?
How did the RPi3 go fitting into the head?
Did you find any problems with the poppy api and RPI3?
I’m thinking of swapping over now.
Lots of questions :wink:

Cheers!


#19

It fits in the head but it is not natural. Concerning issues, yes, I have one issue, I installed the Poppy environment once and now it does not work. The issue is that I have no time to troubleshoot now.


#20

John,

The Poppy we built at Waterloo University in June for the Nengo Summer School (see this thread) was with a Raspberry Pi in the head. I hot glued it on the supports for the head_y servo with the USB sockets facing the cutout for the Ethernet at the back. I used a cutter to enlarge the hole for the Ethernet and placed 2 USB2AX in those USB sockets. The dongles stick out from the head but it’s fine - looks like someone having a deep cortical implant.