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
@joaomoura24 and I have been discussing that the topic joint_states/target maybe should be renamed to joint_states/command to remain consistent with conventions in robot control. Additionally, the topic joint_states/target uses a sensor_msgs/JointState message type which is usually reserved for reading joint_states, not for commanding. Perhaps a more standard message type should be used for commanding joints such as std_msgs/Float64MultiArray.
The text was updated successfully, but these errors were encountered:
I think the best thing is to create a flag that the user can set in the robot yaml configuration file, e.g. target_message_type: 'JointState' # or 'Float64MultiArray'. First you will need to implement extractor methods, e.g.
@staticmethoddefget_target_from_joint_state_msg(msg: JointState):
# TODO: convert JointState to listreturnq@staticmethoddefget_target_from_float64multiarray(msg: Float64MultiArray):
# TODO: convert Float64MultiArray to listreturn
@joaomoura24 and I have been discussing that the topic
joint_states/target
maybe should be renamed tojoint_states/command
to remain consistent with conventions in robot control. Additionally, the topicjoint_states/target
uses asensor_msgs/JointState
message type which is usually reserved for reading joint_states, not for commanding. Perhaps a more standard message type should be used for commanding joints such asstd_msgs/Float64MultiArray
.The text was updated successfully, but these errors were encountered: