-
Notifications
You must be signed in to change notification settings - Fork 103
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
Conversation
…vn revision 25887)
… provided is for the iCub simulator
Is the robotmotorgui working maybe with limited functionalities in the following conditions?
From: elen4 [mailto:notifications@github.com] 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: Commit Summary
File Changes
Patch Links:
— |
Maybe this proposal could sound like heretic, by I do believe that I mean, calibrations parameters and home postions are already inside the Let's simply change the calibrator module in such a way that when it The only parameters will left in the robotMotorGui will be the default I say this also because in order to use the motorGui with the coman I Alby On 24/01/2014 09:36, Lorenzo Natale wrote:
|
I like this proposal and it does not sound heretic at all :) |
Makes sense. A couple of considerations:
From: barbalberto [mailto:notifications@github.com] Maybe this proposal could sound like heretic, by I do believe that I mean, calibrations parameters and home postions are already inside the Let's simply change the calibrator module in such a way that when it The only parameters will left in the robotMotorGui will be the default I say this also because in order to use the motorGui with the coman I Alby On 24/01/2014 09:36, Lorenzo Natale wrote:
— |
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? |
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 :) |
@lornat75 |
@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 |
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] @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 — |
Yes, with pleasure. |
closing... |
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).