-
Notifications
You must be signed in to change notification settings - Fork 71
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
Migration from ROS1 to ROS2 fails with Boot Issue: Value of object 1018:03 from CANopen device is different to value in object 1F87 (Revision number) #301
Comments
The problem you describe occurs when the eds/dcf you feed to cogen or dcfgen has different values indicated for object 1018 s3. This indicated your drive has another Revision than the eds. You can omit the check by adding revision_number: 0x0 to the slave in bus.yml. Then rebuild. By the way, we do not support math Operations in the scaling factors yet, it needs to be a plain factor. |
Thanks @hellantos
We added these lines in the bus.yaml:
And we got the same error with 1F88, so we added
That was a copy-paste issue when migrating from ROS1 canopen to ROS2 canopen 😸 We are now experiencing a problem that is the same as discussed in #298 I will close this one. |
I have the same problem. The setup is as OP wrote, only the device is different (Nanotec PD4E motor).
Also, I see during the build cogen or dcfgen throws a warning:
I worked around this problem by manually reading the 1018:03 object from motor and correcting it in the EDS. |
Setup
We have a working ROS1 canopen setup that drives two motors, each motor has its own controller (which is a slave in the CAN).
We have followed the ros2_canopen documentation to migrate our setup to ROS2.
Describe the bug
The launch process waits for slaves to boot while the slaves have already send their boot-up message.
After sending a 000#82.00 message on the can, the slaves boot a second time and the launch process continues.
The first output after continuing is an error:
Boot Issue: Value of object 1018:03 from CANopen device is different to value in object 1F87 (Revision number).
This is the only error in the launch process. The launch process ends with:
[canopen_402_driver]: Fault reset
After that, the master sends messages with id 601 id's and the slaves are answering with 580 id's.
So the can should work some how.
We changed the mode of the slaves with the service to
position_mode
, but the response was "success=False".The launch Terminal said "Mode is not supported".
I think the service should be supported, because the service is built.
Is the ros2_canopen package missing some implementation here?
I am trying to control motors with the slaves.
My idea was to use the target Service or the 0x607A RPDO. Both did not work.
When sending RPDO's on the topic nothing happens.
Setup:
bus.yml
Question
Do you have an idea where this problem is come from or a stable solution to control slave motors?
The text was updated successfully, but these errors were encountered: