Understanding pi internal runtime

[yklInverted]

First, thank you for making this incredible work open source!

I'm currently working on bimanual ARX R5, and I'm building my inference environment following the aloha_real example. I noticed that there is an adapt_to_pi transform which you use to convert the action values from Aloha space to a PI internal runtime. Since according to the paper you used 7 different robots, with different dimensions and physical structure, could you share some insights on how did you 'aligh' them into a standard internal runtime?

Also, from my understanding, there are similar adapt_to_pi transforms you adopted for bimanual ARX R5 and other robots. I think it would be helpful for finetuning model on my robot if the corresponding adapt_to_pi transform could be revealed. Otherwise to the model I'm using a new robot it hasn't met before.

Thanks again for your contributions, and any help on this would be greatly appreciated!

[swagh1611]

Check this : https://github.com/Physical-Intelligence/openpi/issues/278

[Michael-Equi]

Hi @yklInverted, since the aloha runtime is open source we were able to check our implementation against it and write the adapt_to_pi function to align the data between runtimes. As I do not know your exact ARX R5 controller implementation, it would be hard for me to tell you exactly what transformation maps between your format and ours. To give you a sense for our internal ARX joint space I can list off the directions and general magnitudes.

J0-J5: CCW is positive, units are in radians, and observations and actions have the same scale Gripper: Action goes from 4 (open) to 0 (closed) and the corresponding observation is from 0.325 to 0. The awkwardness here is mostly just historical reasons and at one point aligned with the default ARX runtime.

We also lowered the gains on the PD controller from the original out-of-the-box ones provided by ARX. For simpler tasks I wouldn't expect this to make much of a difference.

Hopefully this helps!