Modified motion file resulting in world.env.check_valid_episode() returning False at each update

[sahiljuneja]

I was trying to run some experiments of my own. I took two motion files - humanoid3d_kick.txt and humanoid3d_punch.txt and concatenated them for a quick test. I ran the resulting mocap clip, and it ran as expected (initial kick action followed by punch action). No particular issues that I could identify.

I then tried to train using this new motion file (made sure had a corresponding file in args). But I got only an infinite loop of -

Agent 0
Samples: 0

That corresponds to the _train() function in rl_agent.py, right before -

if (self._total_sample_count >= self.init_samples):

So, the above if condition doesn't turn True at any point. After some digging, it seems like the world.env.check_valid_episode() call in the update_world function in DeepMimic.py is returning False for every substep.

And I am currently unsure why that would be, because the valid episode check leads to DeepMimicCore which is a bit beyond my current understanding.

Any insights on why such an approach might not be working? Or is there anything else I need to modify for a custom motion file like the one I mentioned above to work?

[xbpeng]

The invalid episode flag is raised whenever the simulation blows up. Your concatenation of multiple reference motions might be causing the simulation to blow it when it's initialized to the transition between the two motions. Since there is probably a sudden change in the pose between the two motions, which can result in a large velocity that could cause the sim to blow up. But this should only happen when initializing the character to the timestep between the two motions, which should be quite rare. So it's strange that it will be returning valid episode at every transition. You probably need to dig into the code a bit more to see what causes the invalid episode.

[sahiljuneja]

This is helpful. Thanks!

I will first try to create a smoother blend of the two motions or try out different combinations as well which might allow for that sudden change. Will start digging through the code based on that. I tried to trace the issue but then reached the C++ code and that was a bit beyond my current level of understanding.

Will update if I find something. Thanks again.

[sahiljuneja]

Most likely found the problem source based on your reply.

As per the mocap data format, the first value for each frame is the duration of frame in seconds (1D)

At the end of each motion, the duration of the frame is set to 0.000000. A simple, direct concatenation causes that to appear twice, because of each motion.

Removing that particular frame for the first motion seems to be resulting in the training moving forward as expected. I will close this for now since the original issue is resolved.

[xbpeng]

Good catch, glad you figured it out!