Multiple Joint State Topics

[n0sc3tipsum]

Hi,

I am trying to use this package to read joint states of two of my wheels which are being published by an ESP32 via a Micro-ROS agent. As of now, I have made it so that each wheel state is published to its' own topic.

So I am a bit unsure of how this would integrate with this package.

• Should I publish both wheel states as their own messages to a single topic
• Is there a way to have two individual topics where joint states can be published?
• Or is there a message that would contain the joint states of multiple joints?

Thank you!

[hijimasa]

The line 151 in topic_based_system.cpp shows this package only saves latest joint state topic.
So I think you should publish a single topic that integrates each wheel state from your ESP32.

The topic that this package publishes contains the joint commands of multiple joints.
The correspondence between joint names and joint commands should be checked.

[n0sc3tipsum]

The line 151 in topic_based_system.cpp shows this package only saves latest joint state topic. So I think you should publish a single topic that integrates each wheel state from your ESP32.

The topic that this package publishes contains the joint commands of multiple joints. The correspondence between joint names and joint commands should be checked.

Hi, thanks for the response. So you mean I just publish both messages independently or would I have to join them into a single message?

[hijimasa]

You should join each wheel states into a single message.

[n0sc3tipsum]

Oh okay I see, thank you so much! One last question, would that message be a joint state sequence then?

[hijimasa]

What do you mean a joint state sequence?

[n0sc3tipsum]

As in, since I'm using micro-ROS, they have a message type for Joint State messages that forms a sequence (vector of joint state messages I feel like)

/**
  * This is a message that holds data to describe the state of a set of torque controlled joints.
  *
  * The state of each joint (revolute or prismatic) is defined by:
  *  * the position of the joint (rad or m),
  *  * the velocity of the joint (rad/s or m/s) and
  *  * the effort that is applied in the joint (Nm or N).
  *
  * Each joint is uniquely identified by its name
  * The header specifies the time at which the joint states were recorded. All the joint states
  * in one message have to be recorded at the same time.
  *
  * This message consists of a multiple arrays, one for each part of the joint state.
  * The goal is to make each of the fields optional. When e.g. your joints have no
  * effort associated with them, you can leave the effort array empty.
  *
  * All arrays in this message should have the same size, or be empty.
  * This is the only way to uniquely associate the joint name with the correct
  * states.
 */
typedef struct sensor_msgs__msg__JointState
{
  std_msgs__msg__Header header;
  rosidl_runtime_c__String__Sequence name;
  rosidl_runtime_c__double__Sequence position;
  rosidl_runtime_c__double__Sequence velocity;
  rosidl_runtime_c__double__Sequence effort;
} sensor_msgs__msg__JointState;

// Struct for a sequence of sensor_msgs__msg__JointState.
typedef struct sensor_msgs__msg__JointState__Sequence
{
  sensor_msgs__msg__JointState * data;
  /// The number of valid items in data
  size_t size;
  /// The number of allocated items in data
  size_t capacity;
} sensor_msgs__msg__JointState__Sequence;

#ifdef __cplusplus
}
#endif

#endif  // SENSOR_MSGS__MSG__DETAIL__JOINT_STATE__STRUCT_H_

Or would it just be a case of placing multiple entries into the following structs:

  rosidl_runtime_c__String__Sequence name;
  rosidl_runtime_c__double__Sequence position;
  rosidl_runtime_c__double__Sequence velocity;
  rosidl_runtime_c__double__Sequence effort;

[hijimasa]

Sorry, I don't know micro-ROS well.
In default environment, two wheel states integrate a single message like below.
Example:
Left Wheel Message

header:
  stamp:
    sec: 1718174785
    nanosec: 886196307
  frame_id: ''
name:
- left_wheel_joint
position:
- 1.0
velocity:
- 2.0
effort:
- 3.0
---

Right Wheel Message

header:
  stamp:
    sec: 1718174785
    nanosec: 886196307
  frame_id: ''
name:
- right_wheel_joint
position:
- 4.0
velocity:
- 5.0
effort:
- 6.0
---

Integrated Message

header:
  stamp:
    sec: 1718174785
    nanosec: 886196307
  frame_id: ''
name:
- left_wheel_joint
- right_wheel_joint
position:
- 1.0
- 4.0
velocity:
- 2.0
- 5.0
effort:
- 3.0
- 6.0
---

[n0sc3tipsum]

Oh I see, I'll try putting in the names and data into the joint state message arrays. Thank you !

[n0sc3tipsum]

Hi,

I was able to get the robot system running and can see the topics for command and state interfaces on my rqt_graph shown below :

However, when I publish twist messages to the \manual_cmd_vel topic using the teleop_twist_keyboard, I don't see anything on the joint_ctrl topic which I specified as the command interface topic. The way I understood it is that the DiffDrive Controller will calculate the forward kinematics given the twist messages and then use the hardware interfaces (topics in this case) to set the actual joint commands - yet Im not sure of how to actually connect the two.

Thanks!

[hijimasa]

I forgot important information.
This package currently does not publish velocity command because it publish the command when position commands are changed.
I send pull request about this issue, but no one is reviewing this.

The simple solution is comment out below line in line 275 in src/topic_based_system.cpp.

return hardware_interface::return_type::OK;

[n0sc3tipsum]

I forgot important information. This package currently does not publish velocity command because it publish the command when position commands are changed. I send pull request about this issue, but no one is reviewing this.

The simple solution is comment out below line in line 275 in src/topic_based_system.cpp.

return hardware_interface::return_type::OK;

Oh right I see. What would commenting out that line do? I also saw your pull requests and wanted to ask if you know if it works with something like the DiffDrive controller, if so, could I use your changes in my project?

[hijimasa]

In the simple solution, joint command is published every time.
So this uses computer resource.

In my pull request, joint command is published when velocity command is not zero.
I checked this for DiffDrive controller with Isaac Sim. So I think you can use it.

[n0sc3tipsum]

Oh epic! I'll try it out.

Thank you!