MyRobotLab - ready to start chatbot Package ( french / english )

[Anthony Gallot]

Hi all ! this is a ready to launch Myrobotlab package.

Usefull to start from scratch or just test the chatbot .

Based on MRL 1351

// DOWNLOAD BETA
www.myai.cloud/Inmoov_IA_V1.zip

- Works with or without servo
- French / English
- chatbot ( wiki awnsers by beetlejuice, internet fetcher, weather, jokes, pictures )

// REQUIREMENTS

java,chrome

//HOWTO

- Unzip to empty folder ( exemple c:\mrl )

- Flash your arduino with ARDUINO-FLASH-V_32.ino in the zip, it's the good MRLCOMM version, MRL need it to move your servo

- Open with text editor script.py and change your settings ( exemple LANG=EN ), don't break all :)

- Click on  mrl.bat to launch ( First exec is very long please wait )

- If you are using other system than Windows, look into the mrl.bat file
- Chrome is now open, you can speak in the "ear" tab or use keyboard in the "chatbot" tab

- You can open a "GUI SERVICE" and many others, on the top of the webgui if you want.

// BUG

Microphone listen the awsers if is near... I try to fix it with hardware tip

Click on the microphone if it respond too long

// CHATBOT COMMANDS

***Look and change if you want into AIML file : develop\ProgramAB\bots\rachel\aiml ***

- show a picture :
SHOW ME ********

- Weather :
WEATHER PLEASE

- Jokes :
TELL ME A JOKE

- Questions

WHAT IS *

WHO IS *

WHAT IS THE * OF *

WHO IS THE * OF *

WHAT IS THE * OF * OF *

QUESTION **** ( this one is called if no awnsers finded before -> it do some internet search, sorry for quality... )

//SOURCES TO MOD !

https://github.com/…/py…/blob/master/home/moz4r/MyaiBot-Aiml
https://github.com/…/pyro…/blob/master/home/moz4r/MyaiBot.py
https://github.com/…/pyrobot…/blob/master/home/moz4r/mrl.bat
DATA files prop.txt / propEN.txt
https://github.com/…/mas…/home/beetlejuice/properties_ID.txt
https://github.com/…/beetlejuice/propri%C3%A9t%C3%A9s_ID.txt

// FRENCH VERSION OF THIS POST

https://www.facebook.com/groups/1556012494689996/permalink/1594302824194296/

Have fun :)

[Kevin Watters]

Looks great !!!   I look forward to chatting with Rachel !  I'm sure she can answer many questions.

It might be easier for folks to use if you have it checked into github..  We created a github place for new chat bots.   

https://github.com/MyRobotLab/aiml/

Rachel would be a great addition,  great work!

[Anthony Gallot]

Thanks you kwatters !  I will add Rachel to the right place she will be happy with friends :) Can I link files in github or i must move them ?

[Kevin Watters]

I think we should figure out what the directory structure should be to define a custom chatbot version of InMoov.  I've also been doing this with Harry.  

I've been using a small startup script that loads the chatbot (ProgramAB) and the InMoov.  Each one of the gestures is defined in it's own python file.  I broke down the full InMoov2 script so that each function was it's own gesture.  The aiml is also checked in.    

// This is the script that loads the chat bot, launches the gui, and starts the inmoov

https://github.com/MyRobotLab/pyrobotlab/blob/master/home/kwatters/Harry.py

// this is the directory where both the gestures and the AIML is stored.

https://github.com/MyRobotLab/pyrobotlab/tree/master/home/kwatters/harry

This is just an example of one way to structure the files.  I think as more ProgramAB / InMoov bots start coming to life, it'd be good to have some standardization on how they are structured.

Let me know what you think,  I know it still needs works to clean up the gesture files...  There also remains a BIG question about how to "calibrate" between different inmoovs for the servo angles.  (everyone's builds are slightly different.)  This is a topic worthy of another post, but I'll share some initial thoughts here first.  

Each servo in the InMoov should have a "min" angle","max angle", "rest angle". 

The jaw servo specifies a min/max angle that represents the open/close position of the mouth.  (this should probably just read off the min/max/rest angles that are already configured, the mouth control service is due for a re-write to clean this up.)

Now, additionally to the min/max angles, there's also a question of calibration between the default standard  (Gael's i01 InMoov, or maybe the VirtualInMoov in blender)) and someones build.  In MyRobotLab, there is the ability to map one set of min/max values to another set of min/max values using the servo map function...  

I think there are 2 approaches to specify the mapping ..  currently the map function on the servo maps the min/max values by scaling them in rectangular coordinates.  This is very effective and realtively easy to specify. (many already use it.)  An example of this might be for the omoplate.  If you've printed out the pot holders for the square pots, they are rotated 90 degrees from the normal inmoov.  The normal omoplate range is from 10 to 80 degrees.  The omoplate min/max are normally set to 10 and 80 degrees respectively.  In the case of the square pots,    these values would need to be mapped from 100 to 180 instead... 

I want to propose another approach that uses a polar coordinate system...  In polar coordinates this stretching could be defined by the angle or rotation by adding 90 degrees.  This 90 degrees could be considered and "encoder offset"  (in polar coordinates, there is also a "gear ratio" , but for most cases this is 1, unless the servo is inverted.  then it's -1 ...) 

Both methods for calibration produce the same result. 

The ultimate goal of this calibration is so we can define the "gestures" in a way that does not specify any "hard-coded" angles...  but rather all the gestures could use the "calibrated" values instead...   This is a pretty big refactor for each of the gestures, but I think it would be a big step towards allowing the community to reuse and share the scripts across multiple builds of the inmoov.

I'm happy to add additional support to MyRobotLab to make this easier, but before I made any major design decisions about it, I first wanted to get some community input.

[Anthony Gallot]

Wahoo wonderfull work . I think too , standardisation is the way to go.  I will try to do like you do your script.

The command : i01.loadGestures(gesturesPath) is a python include ?

 I understand the problem about gesture calibration and it will be great for all to find an universal solution .

Just a little idea , to control gesture : in percent it will be great and comprehensive for all, what do you think ? :

//user setup -> real servo value

My_Min_Head_Value=10

My_Max_Head_Value=80

My_Min_LittleFinger_Value=30

My_Max_LittleFinger_Value=120

...

//Static gesture -> percent value for all  :

i01.moveHead(X_HEAD) ->  always 0 to 100%

i01.moveHand("left",X_LITTLEFINGER) ->  always 0 to 100%

...

Exemple

if X_HEAD=0 ( 0% ) -> user value ( servo value to send ) is : 10

if X_HEAD=10 ( 10% ) -> user value ( servo value to send ) is : 17

if X_HEAD=50 ( 50% ) -> user value ( servo value to send ) is : 45

...

( (My_Max_Head_Value - My_Min_Head_Value) * X_HEAD / 100 ) + My_Min_Head_Value

(if My_Max_Head_Value - My_Min_Head_Value > 0 else invert calc )

...

If you want some fingers when gesture rewrite, i m not far

 

[Kevin Watters]

I've heard some others also mention the idea of using a percentage for the actuation.  We could convert everything to a percentage, but I think that moves us farther from reality.  When we get into building mathematical models for the robot arms, we will be dealing with degrees and angles, not percentages.  So my gut feeling is, that if we ever want to have a formal robot arm description, the proper thing to use is the angle in degrees.   (not a percentage.)  

What I'm thinking is that there's a base angle, and then there's a calibration offset angle that is added to that base angle to perform the calibration.  From my electrical engineering background, we often deal with things in terms of its "gain" and "phase shift" 

The "gain" is accounting for the gearing ratio, and the phase shift is the offset between "true zero" and the "calibrated zero" angles for a given joint.

I'm thinking of something like the following:

CalibratedAngle = (ModelAngle * Gain + Offset) % 360   

This way you can specify the "model angle" for all gestures, and for each servo that's moving, we multiply that by a gain, and add the offset.    Normally the gain is 1 or -1   (-1 in the case of being inverted in it's direction.. )  and the offset is the difference between the zero angle of the model and true zero angle of the actual robot...  

I think either approach will work, but I feel like using a representation that is a percentage gets us away from the physical and mathematical models...  

[Anthony Gallot]

I will try to use your idea to format my scripts . Standardize by angle

[Anthony Gallot]

Just to correct the link post broken ( french post ) : https://www.facebook.com/groups/1556012494689996/permalink/1583357531955492/

The script is updated to 1.5 , but only works in french for now.

ENGLISH VERSION IS BROKEN

I just need some time to translate a little the AIML and dissociate languages in the database.

Version 1.5 : add shared learning capacities between bots

[gael langevin]

Thanks Anthony!

Gael Langevin

Creator of InMoov

InMoov Robot

@inmoov

--
You received this message because you are subscribed to the Google Groups "InMoov" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inmoov+un...@googlegroups.com.
To post to this group, send email to inm...@googlegroups.com.
Visit this group at https://groups.google.com/group/inmoov.
For more options, visit https://groups.google.com/d/optout.

[Anthony Gallot]

Hi friends ! Last update before sun and sand , this is shared knowledge poc

https://www.youtube.com/watch?v=taXwTN6V3OA ( subtitles inside )

There is a lot of modification since the original post, i cant mod it. I will write an other clean post on MRL blog soon

@kwatter nothing relative this video , about gesture standardize why don't you like map functionality ? Why it is better to use standardize by angle


cheers