DiffDriveController – ignores wheels orientation

[lmendyk]

I’m a complete beginner (it is my first constructed robot as a hobby – based on Lego Ev3).

My robot is constructed in a way that wheel motors rotate in the opposite direction to the intended front of the robot.

To mitigate I have corrected the wheel orientation in URDF (modifying the copied diffbot example from ros2 control demos). The effect seems correct in the sense that when I test the URDF in rviz and I change the position of the wheel toward “+” values the wheel frames rotate as phical robots does – in the opposite direction where the base link “red” axis point to.

When started Diff Drive Controller and given the command with Twist message linear x: with positive value I was expecting that the DiffDriveController would take into account the change wheel orientation and would generate the negative speed for wheels so the robot goes towards X positive values.

But the DiffDriverConroller behaves as if nothing has been changed in wheel orientation, so the effect is the “real” robot goes backward, while when visualising in rviz the odom frames are incorrectly showing the robot going Forward.

See the screencast – showing that wheels are rotating as physical robot does, but robot moves to opposite direction to the wheels rotation.
DiffBotEv3.webm

As a workaround – I have changed the polarity of the Ev3 motors, but readings from the ev3 sensor still report the rotation as if the polarity has not been changed -so positive speed reports the position increasing in the negative direction. So the effect was that physical robot was driving forward as intended but Odom frames was showing that robot goes opposite direction (I used open_loop parameter as False – so I guess it is because the reported position of the motor as negative)

I’m using the galactic distribution, but have not found in releases notes for master version that anything has been changed in DiffDriveController in that aspect.

Am I missing something or DiffDriveController “hardcodes/assumes” that wheels rotation move always robot forward (I mean positive speed of wheel moves robot always forward) . I have not found anything in the documentation that robot construction must assure the wheels of the robot rotate in a specific way.

How can I resolve my issue (I would prefer not changing the construction of my robot)

[bmagyar]

Your analysis of the assumptions are correct. Wheels orientation is assumed and it isn't something that could be parametrized in an intuitive way, it's just too hacky...

What I see you are doing is essentially retrofitting the robot code setup to the physical reality. The abstract needs to meet the concrete.

In these cases there are always 2 sets of changes you need to apply:

• "hack" the URDF such that your robot wheel is oriented how it should be in the ideal case
• adjust your SystemInterface such that the "bridge to reality" also inverts the values

How do you interface ros2_control with the EV3?

[lmendyk]

How do you interface ros2_control with the EV3?

I have followed the examples in ros2_control_demos and I have written the “class Ev3SystemHardware : public hardware_interface::SystemInterface ..”.

So yes I could potentially “intercept” values written/read via command and state interfaces and implement the polarity change by “software” for example by negating the velocity being set to Ev3 and negating the position read from Ev3.

[maxpolzin]

The functionality to set each wheels turning direction as a parameter when the controller is loaded is implemented here: https://github.com/rosblox/ros2_controllers/tree/humble

An example usage can be found here: https://github.com/rosblox/pca9685_ros2_control, particularly in this file. The configuration parameters then look like this:

... other_parameters ...
    left_wheel_directions: [-1, 1]
    right_wheel_directions: [1, -1]

Would you like me to create a PR?

[bmagyar]

I'd much rather prefer if we actually parsed the URDF to figure this out. Is that a workable solution with your setup? We have a couple of things pretty much ready to get this working in a week or so

[maxpolzin]

Oh, I most definitely agree and originally assumed that this happens under the hood. I was surprised that the diff_drive_cobtroller wasn't reading the URDF at all.

My implementation works (at least for our cases), but it is more of a workaround along the realization of how other parameters are realized in the controller, e.g. wheel_radius or wheel_distance, which would also be nice to be read from the URDF (potentially together with some error check if a robot is feasible to be controlled with diff_drive_controller).

A downside of reading parameters from the URDF could be another added dependcy. Maybe consistency would be good and read either all or no geometric parameters from the robot's URDF.

Please ping me if your solution is rdy, I am looking forward to have a look at it.