Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

robotMotorGui default configuration file #4

Closed
wants to merge 2 commits into from

Conversation

elen4
Copy link
Contributor

@elen4 elen4 commented Jan 22, 2014

Since the ResourceFinder now searches "robot" directories before "context" ones, it is possible to provide a default configuration file for the robotMotorGui within a context. Current solution, with hard-coded default values, was incomplete, as actually a large number of values are needed for the gui to be fully operational (i.e., for "home" buttons to work), so I reverted related all commits. I changed the default robot name to be icubSim, so that it's easier to understand whether the robot-specific or default file has been loaded (and also because I assume that if a robot is on installed on a machine, the user is working with the simulator; anyway, I think that the simulator at some point should have a set of configuration files that match the real robots ones and that are found in the same way).

@lornat75
Copy link
Member

Is the robotmotorgui working maybe with limited functionalities in the following conditions?

  •    No YARP_ROBOT_NAME exists
    
  •    YARP_ROBOT_NAME specifies the correct robot
    

From: elen4 [mailto:notifications@github.com]
Sent: mercoledì 22 gennaio 2014 16:50
To: robotology/icub-main
Subject: [icub-main] robotMotorGui default configuration file (#4)

Since the ResourceFinder now searches "robot" directories before "context" ones, it is possible to provide a default configuration file for the robotMotorGui within a context. Current solution, with hard-coded default values, was incomplete, as actually a large number of values are needed for the gui to be fully operational (i.e., for "home" buttons to work), so I reverted related all commits. I changed the default robot name to be icubSim, so that it's easier to understand whether the robot-specific or default file has been loaded (and also because I assume that if a robot is on installed on a machine, the user is working with the simulator; anyway, I think that the simulator at some point should have a set of configuration files that match the real robots ones and that are found in the same way).


You can merge this Pull Request by running

git pull https://github.com/elen4/icub-main robotMotorGuiConfig

Or view, comment on, or merge it at:

#4

Commit Summary

  • robotMotorGui: revert commits to main.cpp back to 2a34ba1 (original svn revision 25887)
  • Added default context "robotMotorGui" for robotMotorGui; default file provided is for the iCub simulator

File Changes

Patch Links:


Reply to this email directly or view it on GitHubhttps://github.com//pull/4.

@barbalberto
Copy link

Maybe this proposal could sound like heretic, by I do believe that
robotMotorGui /should not have any parameter at all!/

I mean, calibrations parameters and home postions are already inside the
robotInterface files.

Let's simply change the calibrator module in such a way that when it
receives the calibration command (void) , it will use the data it
already has read from the file at startup. It is calibrating at startup,
so just re-do the very same thing.
Same for the homing position.

The only parameters will left in the robotMotorGui will be the default
list of parts and the robotName, which is the same for all icubs.

I say this also because in order to use the motorGui with the coman I
had to fill the config file with completely useless data, because their
robot do not have a calibration procedure, but still the motorGui needs
calibration parameters!

Alby

On 24/01/2014 09:36, Lorenzo Natale wrote:

Is the robotmotorgui working maybe with limited functionalities in the
following conditions?

  • No YARP_ROBOT_NAME exists
  • YARP_ROBOT_NAME specifies the correct robot

From: elen4 [mailto:notifications@github.com]
Sent: mercoledì 22 gennaio 2014 16:50
To: robotology/icub-main
Subject: [icub-main] robotMotorGui default configuration file (#4)

Since the ResourceFinder now searches "robot" directories before
"context" ones, it is possible to provide a default configuration file
for the robotMotorGui within a context. Current solution, with
hard-coded default values, was incomplete, as actually a large number
of values are needed for the gui to be fully operational (i.e., for
"home" buttons to work), so I reverted related all commits. I changed
the default robot name to be icubSim, so that it's easier to
understand whether the robot-specific or default file has been loaded
(and also because I assume that if a robot is on installed on a
machine, the user is working with the simulator; anyway, I think that
the simulator at some point should have a set of configuration files
that match the real robots ones and that are found in the same way).


You can merge this Pull Request by running

git pull https://github.com/elen4/icub-main robotMotorGuiConfig

Or view, comment on, or merge it at:

#4

Commit Summary

  • robotMotorGui: revert commits to main.cpp back to 2a34ba1
    (original svn revision 25887)
  • Added default context "robotMotorGui" for robotMotorGui; default
    file provided is for the iCub simulator

File Changes

Patch Links:


Reply to this email directly or view it on
GitHubhttps://github.com//pull/4.


Reply to this email directly or view it on GitHub
#4 (comment).

@pattacini
Copy link
Member

I like this proposal and it does not sound heretic at all :)

@lornat75
Copy link
Member

Makes sense. A couple of considerations:

  •    Unless I am mistaken the ‘granularity” for calibration at the level of the motor gui is single joint while the calibrator your want to remotize calibrates a whole part. If anybody agrees this is not an important feature then it is fine.
    
  •    Some parameters could be useful: i.e. name and list of robot parts and robot name, this allows more generality (although all robots in the future will be humanoid ;) )
    

From: barbalberto [mailto:notifications@github.com]
Sent: venerdì 24 gennaio 2014 09:46
To: robotology/icub-main
Cc: Lorenzo Natale
Subject: Re: [icub-main] robotMotorGui default configuration file (#4)

Maybe this proposal could sound like heretic, by I do believe that
robotMotorGui /should not have any parameter at all!/

I mean, calibrations parameters and home postions are already inside the
robotInterface files.

Let's simply change the calibrator module in such a way that when it
receives the calibration command (void) , it will use the data it
already has read from the file at startup. It is calibrating at startup,
so just re-do the very same thing.
Same for the homing position.

The only parameters will left in the robotMotorGui will be the default
list of parts and the robotName, which is the same for all icubs.

I say this also because in order to use the motorGui with the coman I
had to fill the config file with completely useless data, because their
robot do not have a calibration procedure, but still the motorGui needs
calibration parameters!

Alby

On 24/01/2014 09:36, Lorenzo Natale wrote:

Is the robotmotorgui working maybe with limited functionalities in the
following conditions?

  • No YARP_ROBOT_NAME exists
  • YARP_ROBOT_NAME specifies the correct robot

From: elen4 [mailto:notifications@github.com]mailto:[mailto:notifications@github.com]
Sent: mercoledì 22 gennaio 2014 16:50
To: robotology/icub-main
Subject: [icub-main] robotMotorGui default configuration file (#4)

Since the ResourceFinder now searches "robot" directories before
"context" ones, it is possible to provide a default configuration file
for the robotMotorGui within a context. Current solution, with
hard-coded default values, was incomplete, as actually a large number
of values are needed for the gui to be fully operational (i.e., for
"home" buttons to work), so I reverted related all commits. I changed
the default robot name to be icubSim, so that it's easier to
understand whether the robot-specific or default file has been loaded
(and also because I assume that if a robot is on installed on a
machine, the user is working with the simulator; anyway, I think that
the simulator at some point should have a set of configuration files
that match the real robots ones and that are found in the same way).


You can merge this Pull Request by running

git pull https://github.com/elen4/icub-main robotMotorGuiConfig

Or view, comment on, or merge it at:

#4

Commit Summary

  • robotMotorGui: revert commits to main.cpp back to 2a34ba1
    (original svn revision 25887)
  • Added default context "robotMotorGui" for robotMotorGui; default
    file provided is for the iCub simulator

File Changes

Patch Links:


Reply to this email directly or view it on
GitHubhttps://github.com//pull/4.


Reply to this email directly or view it on GitHub
#4 (comment).


Reply to this email directly or view it on GitHubhttps://github.com//pull/4#issuecomment-33206064.

@pattacini
Copy link
Member

Uhm, I'm afraid it is useful to have the granularity at joint level indeed... Could it be easy to let the calibrator accept such a command?

@barbalberto
Copy link

Yes, of course the joint level granularity of calib and homing can be done... by changing a little bit the cailbrator interface (again).

My main concern is that I believe a default file which contains calibration parameters could be dangerous, since they are specific for the robot.

robotName and parts could be into a default file that can be placed everywhere we like.

In my ideal world, robotName will be read from YARP_ROBOT_NAME and parts will be discovered by asking the robotInterface, but this is a whole different point :)

@elen4
Copy link
Contributor Author

elen4 commented Jan 24, 2014

@lornat75
without this PR, the robotMotorGui is fully working if YARP_ROBOT_NAME is set and a robotMotorGui.ini is found in the robot directory; it is working with limited functionalities (i.e., the Home buttons don't work) otherwise. So, this PR is mainly concerned with the use of robotMotorGui for the simulator (and no calibration parameters are provided, it's the same file that was in app/default before - @barbalberto why do you need calibration parameters in coman, if the Calib buttons are disabled by default?). @barbalberto at the moment I see some drawbacks to your idea, mainly that not all robots (nor the simulator...) use the robotInterface and we don't have configuration files for them. I think I discussed with @randaz81 that at some point robotMotorGui could have, as parameters, the path and xml tags to use to retrieve the relevant information in the xml files; or, parameters could be asked to the RI, but this is a debate I am not getting into :)
On a side note, I am not sure how robotName for the robotMotorGui (i.e., "icub", it's used to find remote ports) can be retrieved from YARP_ROBOT_NAME (i.e., "iCubGenova01"), is the information written in some specific file?

@barbalberto
Copy link

@elen4 : yes, you are right. Calibration param are not strictly needed to launch the motorGui, my memory fails sometime, sorry.

Btw I do not want to get off the topic (the default robotMotorGui config file), it was just something to think about for the future to avoid duplication of parameters.

To implement this behaviour the only thing needed is that some piece of code inside the robot implements the calibrationInterface (where needed); then it is not relevant if it is started using the robotInterface, the iCubInterface or whatever.

about the side note, I said "in my ideal world" and in that world more robots are cooperating between them, and ports are opened with their full name (i.e., "iCubGenova01") and not just "icub" Tiè :-P

@lornat75
Copy link
Member

I think we can safely enhance the calibration routines in RI to avoid the need for robotMotorGui to know calibration parameters, but you have to check with Marco R and Marco M if this is ok with them, because calibration parameters in the robotMotorGui could be used when robots are tested/tuned.

@barbalberto: can you lead this task? I can’t.

From: barbalberto [mailto:notifications@github.com]
Sent: venerdì 24 gennaio 2014 11:36
To: robotology/icub-main
Cc: Lorenzo Natale
Subject: Re: [icub-main] robotMotorGui default configuration file (#4)

@elen4https://github.com/elen4 : yes, you are right. Calibration param are not strictly needed to launch the motorGui, my memory fails sometime, sorry.

Btw I do not want to get off the topic (the default robotMotorGui config file), it was just something to think about for the future to avoid duplication of parameters.

To implement this behaviour the only thing needed is that some piece of code inside the robot implements the calibrationInterface (where needed); then it is not relevant if it is started using the robotInterface, the iCubInterface or whatever.

about the side note, I said "in my ideal world" and in that world more robots are cooperating between them, and ports are opened with their full name (i.e., "iCubGenova01") and not just "icub" Tiè :-P


Reply to this email directly or view it on GitHubhttps://github.com//pull/4#issuecomment-33212628.

@barbalberto
Copy link

Yes, with pleasure.
I will start working on this starting from (I hope) next week.

@pattacini
Copy link
Member

robotMotorGui is going to disappear from within icub-main and enter the world of yarp under the livery of yarpmotorgui.

closing...

@pattacini pattacini closed this Mar 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants