More ServoGui updates, also notice the (save, load, refresh) buttons on the top right.  I got tired of having to start a python service and doing a  :
servo.broadcastState()

Same goes for load & save.

If speed control is selected the regularly disabled speed settings are enabled.  500 is the default max & default start setting.

Still a "work in progress" as moz4r refers to it :)

This is the new HobbyServoGui.   HobbyServo has 2 distinct concepts of messages & positions.  There are command messages & status messages ... as there are command positions and status positions.   
Commands - are what I want this service to do or be.  Status - is what it reports itself.

That's why there are 2 positions printed - the dark black is my command, the light grey is what position the servo reports.

Power control section still under construction.  "I as a user (if I want speed control) would like to know the best guess to my servos speed - this is necessary without a "real" hardware encoder"  
Most servos seem to have an "operating speed" and its commonly expressed as 0.12 seconds/ 60 degrees
So is 500 degrees a second the unit measurement we should use ?

As you can see this HobbyServo is attached to a TimeEncoder (which is a chunk of software which guesses what a real encoder would behave like) 

If you look at the top right - you'll notice "all" services now have the ability to load or save - but currently a "load" doesn't get a servo back to its original working state - which I would expect.  There was some attempts to generate python and an output script which could do it.

It's a challenge to get back to the original state of some running system.  Not sure if generating python would be the best.

 

I had some questions about the servo gui.   I think internally if Velocity is set to null its not being used.  From the gui perspective - it would be blank.  I'm guessing the graphic is showing the "old" way of -1 being full speed? So, I'll need to get rid of that.  You either put in a velocity or don't use it - this is what determines if you are using speed control.  The buttons need a little refactoring so they aren't all squished. Also, I think it could be compacted some .. there is a lot of blank space.  

Your welcome to suggest other improvements...  (the nice thing about gui's is everyone can potentially have an opinion on it since its visible - regardless of the implementation)

moz4r

5 years ago

Refactor time :)

Beyond the graphic representation that need a little facelift is the question of velocity management. If I follow you since the scripting part:

no velocity control, so max servo can do -> servo.setVelocity (null)
velocity set to 0, so no move -> servo.setVelocity (0)

I think the control of velocity is not used enough it will probably help, but it is limited with hobbie servo, but mrl offer tools to deal with it.

More generally the goal of this HMI was to provide a very minimalist interface for calibrating the servos and that the data be recorded using service.save (). Either directly in the conf files or by exporting the python commands for a DIY script. Not yet used but close to.

tabassumone

5 years ago

Hello everyone...

 

I am building inmoov right hand but controlling with myrobotlab gesture creation i got everytime one error like "com 2 did n't get response from arduino",can't write to closed port and arduino->mrl error.

 

please help me out i am dealing with this for last 2 months but i failed to solve this.

 

i tried changing com port of arduino and python script config but i failed there also.

Ahoy tabassumone and Welcome !

Step 1 - did you load MrlComm on you Arduino
Step 2 - can you connect to the Arduino with an Arduino service, can you control the single Servo

(All this can be done without InMoov scripts, and only the gui)

start with small careful steps and you will eventually travel far

tabassumone

5 years ago

Thank you i solved that issue 1st one is mrl is outdated and 2nd one is just because greedy nature of command i had to stop mrl instances and manage my task by task manager.

 

but when i try to control right hand through voice it is not working,i am sure there is no any interface issue i might have change default configuration of webkit recognition that is why my voice is not audible to virtual inmoov.Kindly help me out.

 

i am not getting any errors every thing is perfectly fine but my robo not responding to my voice command.I am working on this fingerstarter.voice.py

#file : InMoov.minimalFingerStarter.py # MRL version >= Nixie # this script is provided as a basic guide # most parts can be run by uncommenting them # InMoov now can be started in modular pieces through the skeleton.config # although this script is very short you can still # do voice control of a FingerStarter or hand # It uses WebkitSpeechRecognition, so you need to use Chrome as your default browser for this script to work # Change to the port that you use rightPort = "COM9" ############## #to tweak the default voice Voice="Mark" #Male US voice #Voice="cmu-slt-hsmm" #Default female for MarySpeech mouth = Runtime.createAndStart("i01.mouth", "MarySpeech") #mouth.installComponentsAcceptLicense(Voice) mouth.setVoice(Voice) ############## # starting InMoov service i01 = Runtime.create("i01", "InMoov") #Force Arduino to connect (fix Todo) right = Runtime.createAndStart("i01.right", "Arduino") right.connect(rightPort) ############## # Starting parts i01.startEar() # Start the webgui service without starting the browser webgui = Runtime.create("WebGui","WebGui") webgui.autoStartBrowser(False) webgui.startService() # Then start the browsers and show the WebkitSpeechRecognition service named i01.ear webgui.startBrowser("http://localhost:8888/#/service/i01.ear") # As an alternative you can use the line below to show all services in the browser. In that case you should comment out all lines above that starts with webgui. # webgui = Runtime.createAndStart("webgui","WebGui") ############## i01.startMouth() ############## rightHand = Runtime.create("i01.rightHand","InMoovHand") # Tweaking defaults settings of right hand # Mapping by setting your servo limits rightHand.index.map(0,180,42,160) # Rest position rightHand.index.setRest(0) ############## i01 = Runtime.start("i01","InMoov") ############## i01.startRightHand(rightPort) #i01.rightHand.setAutoEnable(True) ############## # Verbal commands ear = i01.ear #always listen #ear.setAutoListen(True) ear.addCommand("attach your finger", "i01.rightHand.index", "enable") ear.addCommand("disconnect your finger", "i01.rightHand.index", "disable") ear.addCommand("rest", "i01.rightHand.index", "rest")## Hardcoded gesture ear.addCommand("open your finger", "python", "fingeropen") ear.addCommand("close your finger", "python", "fingerclose") ear.addCommand("finger to the middle", "python", "fingermiddle") ear.addCommand("capture gesture", ear.getName(), "captureGesture") ear.addCommand("manual", ear.getName(), "lockOutAllGrammarExcept", "voice control") ear.addCommand("voice control", ear.getName(), "clearLock") # Confirmations and Negations are not supported yet in WebkitSpeechRecognition # So commands will execute immediatley # ear.addComfirmations("yes","correct","yeah","ya") # ear.addNegations("no","wrong","nope","nah") ear.startListening() def fingeropen(): i01.rightHand.index.setVelocity(20)## Low velocity i01.moveHand("right",0,0,0,0,0,0)## Thumb,index,majeure,ringfinger,pinky,wrist i01.mouth.speak("ok I open my finger") def fingerclose(): i01.rightHand.index.setVelocity(50)## Medium velocity i01.moveHand("right",180,180,180,180,180,90) i01.mouth.speak("my finger is closed") def fingermiddle(): i01.rightHand.index.setVelocity(-1)## Maximum velocity i01.moveHand("right",90,90,90,90,90,90) i01.mouth.speak("ok you have my attention")

 

calamity

5 years ago

I think the first thing you should determine is to what the speed/velocity apply to.

  • to the input value: 
  • to the output value
  • to the physical rotation of the servo

It could be apply to any of these three with different meaning. What if I use an input value a -1 to 1, an output 0-180 with a gear box with a 1:5 ratio? What value do we want to check. In that case all those value are the same 

  • input : 1 unit/sec (value compute by another service or give by the user)
  • output: 90 position/sec (report by the servo, mesure by the pot)
  • servo rotation: 450 degree/sec (what the servo actually doing)

So it really need to clear out what the speed is apply to, to avoid using different value for the same thing. Or else it could have confusion.

In my view, it should apply to the input value and be called unit/second, because the input value may not be degree value, it could be position value, like min/max. It's also a way to get the concept of 'servo' isolated or abstract in a bigger project. Once set, the servo concept could be 'forgotten' and just use the scale of movement that fit the project.

 I think the concept of input/output is still not well understood. Error about this concept have been done in the past and they should be avoid again.

 

 

Hi Calamity !

So happy to see you post ;)

I as a user only supply "input" ....
It's all about the input .. this is how I supply control or command messages, and the "input scale" should be how its reported back to me.

I'm not sure the "map" or output should be owned by ServoControl .. its more a detail of the ServoController - but it could be Servo specific.  So, what should be happening is the ServoController should be keeping ServoControl specific information regarding on how to translate the data.

But, ServoControl keeps the "input standard" - whatever unit we decide on for input, every ServoController will need to deal with.   So what is it ?   Degree's per second (rotational) .. Inches per second linear ? (Blech I hate Imperial units !) ...

We will need to make a constitution of units per time for ServoControl ... It will be our standard

All ServoController must abide to this standard.

What's the standard ?  degrees per second ? cm per second ? degrees per millisecond ? radians per second ?  cubits per second ? 

we seem to be on the same page about ServoControl.

 

ServoControl take the input the user set and servoController translate that info what is usable by the hardware.

So the servoController don't need to have speed control as it could translate it from what is given by the servo control. So more speed control on the controller is irrevellent

I'm pretty sure I have design servo.setVelocity to be degree/s. On the arduino side, the value is compute with ms delay (depending on how quck the main loop takes)

Hello,

I like the new setup for servo ui.

Though, wondering why is the gui stating "speed" when we changed only sometime ago to "velocity".

I remember a non ending debate about that, that went on for months...

"speed" was finally deprecated for "velocity"

Does this modfication means we need to modify all gestures within InMoov/gestures.python since it now goes from 0 to 500 instead of 1 to 99 (-1 if no velocity defined)

Will this modification have influence as when we switched to "velocity", (gestures were not performing the same anymore)

 

And if I may also suggest a graphical modification, the "rest" button with it's "number position" is a bit awkward to understand for somebody new. The previous logic was better.

Hii Gael happy to see u here..i need to known it is urgent..plz tell me to run all 6 servo efficiently what should be the safe operating voltage..

I am using 4 AA battery of 1.5 volt but not getting satisfied/smooth result.I am trying to move my inmoov right hand and forarm.kindly reply as soon as possible. Should i change supply voltage ?.

Hello,

4 AA will be okay to run just 1 servo, not more...

For the hand you should go for something much more powerfull.

For to run only the hand you could get a 6V 1,3AH battery.

But if you plan to run more than just a hand, you should get a 6V 12AH battery.

Or a decent power supply 6V 50Amps.