You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working with a set of 18 RX-64 motors which are having another issue similar to this issue, which means that reading from the motors fails.
However my issue is the behaviour that arises when reading fails but writing succeeds. The way it works at the moment, is that the joint positions array is initialized with 0. If the read fails, this value stays 0 and it is assumed that this is the current position of all joints. And until any goal positions are sent by my ROS node, 0 is written to the motors as a goal position. In my case this caused the robot to crash into itself, which I guess is my fault as I did not set angle limits on the motors because my limits are set within ROS.
I feel that even though major harm can be avoided by setting angle limits of the motors, this should not be the intended behaviour. If reading the positions fails, it should not store 0 as the current position to prevent the unintended writes of 0.
The text was updated successfully, but these errors were encountered:
BenKlee
changed the title
Unwanted behaviour when reading from motors fails
Unwanted behaviour when reading fails but writing succeds
Jul 30, 2024
BenKlee
changed the title
Unwanted behaviour when reading fails but writing succeds
Unwanted behaviour when reading fails but writing succeeds
Jul 30, 2024
I am working with a set of 18 RX-64 motors which are having another issue similar to this issue, which means that reading from the motors fails.
However my issue is the behaviour that arises when reading fails but writing succeeds. The way it works at the moment, is that the joint positions array is initialized with 0. If the read fails, this value stays 0 and it is assumed that this is the current position of all joints. And until any goal positions are sent by my ROS node, 0 is written to the motors as a goal position. In my case this caused the robot to crash into itself, which I guess is my fault as I did not set angle limits on the motors because my limits are set within ROS.
I feel that even though major harm can be avoided by setting angle limits of the motors, this should not be the intended behaviour. If reading the positions fails, it should not store 0 as the current position to prevent the unintended writes of 0.
The text was updated successfully, but these errors were encountered: