I agree, time has come to marry python and java
and bring Inmoov-os to life!

2 little things we need to talk about before a last polish

- 1 I was implementing an automatic update functionality, so if the script is packaged with the build it will be easier than say "hello world" !!
I know it is better to manually update things in a clean folder, but a worky thing with 0 manipulation "out of the box" will be so great :

Idea process:

> check if remote script github version stable has changed
> Inmoov ask you if he can update himself ( he is polite )
> download myrobtlab.jar to tmp
> shutdown
> replace myrobotlab.jar and reinstall all dependencies ( a vocal warning will occur if mrlcomm need to be uploaded too )

- 2 Sebastien, webmaster of inmoov.fr website is actualy devevop a gui configuration tool to generate multiples .config files and configure servo limits/languages and save personnal data... I will show this post to him and Gael.
This great functionality can be done later, in background

I'm really excited to see that progress you are doing. This is a great way to avoid problem between scripts version and Mrl version.

About the virtual inMoov.

I create initially the virtual inMoov (and IntegratedMovement service) to use as input the real angle a robot part is taking. (this is not the servo position, but let said for the bicep servo, the angle the elbow of the robot will take). We currently have no configuration or setting to set that.

What I use in my inMoov script is mapping the part angle to servo position (instead of map(0,180,minPos, maxPos), I use for example bicep.map(5,60,5,80), so I have a mapping of real angle to servo position.

so to go around that problem, I internally map the servo minInput/maxInput to the default angle for each part of the vinMoov and add a way to override the default angle min max.

I donèt feel that this mapping should happen in the vinMoov service and think it should be elsewhere in the settings. But currently it was the only place I could place it so it work with the generalized way of using the servo map with (0,180, min, max)

So i'm opening the door the the question : Is using map(0,180,min,max) the best way to normalize the gestures so they can be use by different inMoov builds? I personnaly don't think so, but trying to modify that can be a big change.

I agree, there should be no calibration of the virtual inmoov. The virtual inmoov is mathematically correct. It has to be, otherwise, it wouldn't render or move properly.

Ok, so what does that mean.

It means the 0 angle for any joint in the virtual inmoov needs to map to the cooresponding angle for the servo. The servo's 90 degree angle might coorespond to the 0 degree of the virtual inmoov.

This means, the encoder offset (or phase shift) is 90 degrees. In that you have to add 90 degress to the mathematical/virtual model to get to the physical inmoov real world angles.

Ok,, so that's the encoder offset.. pretty straight forward.. next for the "gain". If the servos are actually giving us proper movements, that 90 degrees is actually 90 degrees and that 180 degrees is actually 180 degrees, then the gain is either 1 or -1 ...

If the servo is "inverted" the gain is -1 , which says that it moves in the opposite direction ...

If there is a gearing ratio for the joint, this can be accounted for in the gain. For example the neck servo steps down the servo movements by nearly 3 to 1. So, the gain for that would be 3 to account for the gearing ratio.

I've been on this soap box for a while, and I see it's the easiest way to calibrate between the virtual (DH model) of the inmoov and the physical built model.

The Map function currently happens in rectangular (or cartesean) coordinate system, and that is much less natrual for a rotational movement. (The map function will end up with a divide by zero in some scenarios.. this will not, could not happen in polar coordinates because there is no division to do the mapping.)

So, the calibration between the virtual inmoov & the actual physical inmoov really (in most cases) is just a set of encoder offsets. (in some cases, a gain is added in to account for a servo being inverted or if there is a gear ratio to take into account.)