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

Modify the calibration-delta-updater to consider hard limits #358

Closed
GiulioRomualdi opened this issue Jul 7, 2021 · 5 comments · Fixed by #361
Closed

Modify the calibration-delta-updater to consider hard limits #358

GiulioRomualdi opened this issue Jul 7, 2021 · 5 comments · Fixed by #361
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@GiulioRomualdi
Copy link
Member

Thecalibration-delta-updater is a really useful tool to speed up the calibration procedure.

The application is based on the assumption that the robot has to be manually moved in the zero configuration. Discussing with @pattacini and @S-Dafarra., we realized that a possible solution is to use the hard limits on the robot.

Considering that we can modify the calibration-delta-updater to move the robot towards the hardware limit, automatically compute the offset and finally automatically update the configuration file. To reach the hardware limit we can use the PWM interface (already supported in blf #346) and then we can use the ISensorBridge to read the joint encoder.

cc @traversaro @isorrentino @DanielePucci

@GiulioRomualdi GiulioRomualdi added help wanted Extra attention is needed good first issue Good for newcomers labels Jul 7, 2021
@GiulioRomualdi
Copy link
Member Author

cc @dic-iit/blf-developers

@S-Dafarra
Copy link
Member

S-Dafarra commented Jul 7, 2021

Rather than considering it a special case, a possibility could be to set the individual "expected" values. Those could be all zeros, or the expected encoder measurements when at the limits. I would avoid having an automated way to reach those limits. I think it is safer if a person reaches that configuration by hand.

@GiulioRomualdi
Copy link
Member Author

GiulioRomualdi commented Jul 7, 2021

Rather than considering it a special case, a possibility could be to set the individual "expected" values. Those could be all zeros, or the expected encoder measurements when at the limits. I would avoid having an automated way to reach those limits. I think it is safer if a person reaches that configuration by hand.

In that case, it is super trivial to implement

@S-Dafarra
Copy link
Member

Using the open loop control may make sense for a subset of joints though, like the ankles or the knee. In any case, I think it is not trivial to understand when a joint has actually hit the limit, or instead it is blocked by gravity for example. Also, I am not sure about how to define the signed value of PWM to apply 🤔

@GiulioRomualdi
Copy link
Member Author

In #361 I implemented what you suggested in #358 (comment)

@GiulioRomualdi GiulioRomualdi linked a pull request Jul 8, 2021 that will close this issue
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants