Hi, have some questions trying to use the diffdrivecontroller from ros_control on a real differential drive robot. I try to measure the odometry with a lm393 speed sensor and an encoder disk with 20 slots.

1. The documentation states that diffdrivecontroller works with wheel joints through a velocity interface. However, all the examples I've seen so far that implement a hardware_interface (slaterobotics, eborghi10/myROSmobile_robot) read a position (angle) from the continuous wheel joints. Do I really need to provide the angle of the joints? I am asking because diff_drive_controller seems to use only a velocity interface and no position interface.
2. What's the range that I should put the angle in? [0, 2*pi[, [-pi, pi[ or something else? I am asking for a range because I found out that the angles get wrapped anyway according to this github issue
3. Another question I have is whether the diff_drive_controller uses/requires joint_state_controller for its operation?

Edit: It seems that diff_drive_controller itself doesn't need joint_state_controller to operate correctly. However, when working with ros_control, joint_state_controller is useful to publish joint states for other nodes: that's the way we tell the whole system the current status of the robot joints. If another code wants to do something with the velocity of the joints, for example, here is where it should look for. 4. The example eborghi10/myROSmobile_robot uses two yaml config files. One for the diff_drive_controller and another one for the joint_state_controller and two effort_controllers. Why are all these controllers required for a differential drive robot? I thought that the diff_drive_controller should make the effort_controllers obsolete.

Edit: According to this issue effort_controllers/JointEffortController shouldn't be required. Instead we should use diff_drive_controller because it will have the diff-drive logic already implemented.
5. Is the joint_state_controller just used to publish joint states to nodes not related to ros_control or is this controller actually required for the diff_drive_controller to work properly?

Edit: As mentioned in question 3.: joint_state_controller is useful when working with real robot hardware to publish joint states for other nodes. As far as I understand it is not required for ros_control itself to work. 6. According to this answer we can use the joint_state_publisher to publish JointStates without having hardware and use joint_state_controller together with a hardware_interface and in conjunction with ros_control to publish joint states. The documentation in the source code of jointstatecontroller states this similarly:

   > This controller publishes the state of all resources registered to a `hardware_interface::JointStateInterface` to a topic of type `sensor_msgs/JointState`.

Where do the resources (joints) get registered? [Here in the hardware_interface](https://github.com/eborghi10/my_ROS_mobile_robot/blob/e04acfd3e7eb4584ba0aab8a969a74d6c30eed34/my_robot_base/include/my_robot_hw_interface.h#L193)?

So far I have no hardware_interface but a rospy node that is able to print the rpm and angle (not sure if this is correctly calculated) from the sensor connected to a RaspberryPi 4B. In the code I use python's time.sleep which is probably not what I should do and instead use rospy.sleep? However, my plan was to write this module not depending on ROS client libraries and then use it inside another ROS node that publishes the angle and velocity of the two joints (with JointState message type). In the hardware_interface I would then use a subscriber to read the published joint states inside the hardware_interface::read() method. Would this be possible even if I use python's time.sleep or do I have to switch to using rospy.sleep? Are there better ways to get the velocity and angle (if even needed) read in the hardware_interface and do I need to make use of joint_state_controller?

By the way with the current implementation of the lm393 speed sonsor node I don't get the direction. For this I plan to take the sign of the linear cmd_vel into account, also inside the hardware_interface.