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)
Refactor time :) Beyond the
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)
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.
Hello everyone... I am
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
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
Yes but not through myrobotlab but simply using my arduino IDE.
I am able to control and provided gesture also and controlled my inmoov through neuroSky brain headset but i want to do all this through MyRobotlab. kindly help me out.
Every time i m getting arduino->mrl error bad magic numbers. I am facing issue while interfacing my arduino with myrobotlab.
MRLComm
Hi
Please make sure that you have MRLComm compiled and uploaded to the Arduino from the version of MyrobotLab that you are using. This video explains how to do that. https://www.youtube.com/watch?v=-EQxjpsOJDg
You may still get some error when you start, but they should go away after a few seconds.
Thank you but there is another issue while controlling by voice
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
I think the first thing you
I think the first thing you should determine is to what the speed/velocity apply to.
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
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
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
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
blessed be the metric for they shall .. something i guess.
my vote would be for degrees / second and meters / second as our standard for speed / angular velocity...
as for the mapping..the servoControl interface (or the new one at least) has a setMapper getMapper method where you can pass in a mapper class to handle those details.
I would agree with you
I would agree with you kwatters, however, the current implementation of servo.setVelocity for arduino is degrees/ms !
So .. should HobbyServo.setSpeed(x) make its implementation degrees / second ?
That's the path I'm currently going down ....
I'm pretty sure I have design
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)
I see it now calamity ..
I see it now calamity .. Thanks ! :)
Hello, I like the new setup
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.
Safe operating voltage to run 6 servo properly.
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
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.
Thank you so much for ur kind support.
Thank u so much..it is helpful.