Harder Better Faster Stronger - Is the InMoov Script Ready ?

Hi,
Are we ready to package the latest InMoov script from here https://github.com/MyRobotLab/inmoov
as part of the build process so they will continue to grow in sync ?

The time has come

Definitely a good idea. I guess the question is how to package/bundle it. I feel like we should snapshot it with the release... Similar to how mrlcomm is part of the release.

Maybe part of the build script would zip up the current InMoov scripts and make sure they are a snapshot of when the build ran.

Aye .. I was pretty much

Aye .. I was pretty much thinking 'exactly' how mrlcomm is bundled..

During the build the 'latest' on develop - is there a develop branch? ...

Heh .. guess we should start there :)

Ok a develop branch needs to be created on InMoov repo and - that's where all the development should be taking place.

"No one" - should touch master and only a merge-request during the release process should push commits into master ..

I'll start that step

I agree, time has come to

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 )

wip idea :

https://github.com/MyRobotLab/inmoov/blob/master/InmoovScript/system/up…
https://github.com/MyRobotLab/inmoov/blob/master/InmoovScript/system/up…

- 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

All great ideas Moz4r, I have

All great ideas Moz4r,

I have some general questions, and it would be really good to get Gael's input on them.

I think we all agree we want a script which is 'always' compatible with new releases.

This "Marriage" is a great way to increase our chances considerably, also it simplifies the noobie experience of not having to get different parts from different locations.

We have the potential of incorporating virtual InMoov into this plan too. VirtualArduinos I think are ready, and calamity has put a lot of work into the JMonkeyEngine InMoov simulator.

Let's imagine how a noobie would start :

Cool robot, wonder if I can download something about it ..
Hey ! It comes with a simulator
Ok, I downloaded it, now .. "How do I start it?" (after finding 1 clicky button)
OMG .. IT WORKY !
(plays with script ... makes cause and effect .. WHOA ! I can make a virtual robot do stuff !)
I think I'll get a servo..
Uses cool fingerstarter examples (if creating cool fingerstarter examples is possible ?)
I think I'll get a 3d printer
Starts building InMoov
builds Head ... move to intermediate & advaced :D

So if we think this is the progression, we should try to help guide users through it ?

Virtual InMoov is a fantastic idea.

100% agree. Yes, I think we should merge together the virtual inmoov and the default inmoov scripts so that we're always running the simulator , potentially by default, using a virtual arduino?

Once that's in place the only difference between the finger starter and the full inmoov is which arduinos/servos you have hooked up.

I'm really excited to see

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.

encoder offset and gain

This sort of calibration is much easier done in polar coordinates.

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

The way I'm using mapping

The way I'm using mapping with (minAngle, maxAngle, minServo, maxServo) is actually hiding an encoder manipulation just as you describe.

I could rewrite the mapping function that I use as map(minAngle, maxAngle, (0+minAngle) *gain + offset, (0+maxAngle)*gain + offset).

So it conveniently hide the encoder feature.

so If I have a servo that have no offset/not inverted, doing a map(0,90,0,90) will give the same results as unmap output *1.0(gain) + 0(offset)

ifI use a servo with 90 degree offset/inverted, doing a map(0,90,90,0) will give the same results as unmapped output * -1(gain) + 90(offset)

using the encoder required 4 parametters (min, max, offset, gain), same as map (minInput, maxInput, minOutput, maxOutput)

division by 0 can only happen if either minAngle = maxAngle or minServo = maxServo.

So in this point map and encoding are just different implementation doing the same thing

But the map offer an extra setting that is not taken into account with the encoder (and not used with the map(0,180,min, max) currently used. It allow also changing the input range.

Let me give an example. I build an inMoov shoulder, but use a servo with a range of 90 degree instead of a 180. (with the minimum position having the arm straight toward the ground)

With the way we currently use, the setting will be shoulder.map(0,180,45,135) or something like that
with the encoder way, we will set something like that shoulder.encoder(45(min),135(max),45(offset),1(gain))
with the way I use the mapper, I would do shoulder.map(0,90,45,135)

What will happen if I have a gesture that said moveTo(180), or moveTo(90)

with the current way, moveTo(180) will make the arm move straith forward and moveTo(90) move at 45 degree toward the ground. -> so the arm never move the way the gesture want
with the encoder method, any value of moveTo < 90 will work fine, but value over 90 will be clipped at the output at 135, so it won't go over having the arm straight forward.
A similar behaviour will happen with my way of using map

so both encoder way and the way I use the map have a better behaviour than the current way of setting the servo limits.

But the encoder will required to be implemented in the Servo class, while the Mapper already support what i'm doing

I don't said that the way I'm using Map is the best way, just that I think it's a better way to normalize different buid of inMoov to use common gestures or services that modify the servos positions