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

Sending position command with target velocity #422

Open
mikaelarguedas opened this issue Jan 26, 2021 · 0 comments
Open

Sending position command with target velocity #422

mikaelarguedas opened this issue Jan 26, 2021 · 0 comments

Comments

@mikaelarguedas
Copy link
Contributor

mikaelarguedas commented Jan 26, 2021

Hi there,
Thanks for all the work on this package, this is a great resource!

I'm new to CANOpen and am aiming to command a (set of) motors in position. Currently I can successfully spawn a position controller and make my motor move to the requested position.

It looks like the motor is running at the maximum velocity defined in the URDF. Is there a way to specify a maximum velocity per command ? or a scaling factor for the velocity of the motion ?
I would like for example to do one motion at 1m/s and the next one at 0.1m/s


Looking around this repo I saw some discussion about supporting:

Is any of this related to the solution I'm looking for ? Or is there something already available to accomplish what I'm trying to do ?

Thanks!

Edit: maybe its the ProfiledPositionMode I'm looking for with a way to specify the profile before sending commands ?
It looks like I could set the following objects before each motion to have de different profile for each command: 6081, 6083, 6084. Not sure where is the best way to do it within ros_canopen at the moment

Edit2: I could successfully command a drive in position with velocity profile by setting the objects 6081, 6083, 6084 before each command. This is currently done using the set_object service interface provided by the ros_canopen motor node.
Next steps would be to be able to do this inside the motor node rather than having a node poking its service interfaces. A follow-up would be to be able to set these objects for all drives involved in the motion and sync the beginning of the motion between them

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

No branches or pull requests

1 participant