Remove front_steering from steering library

[qinqon]

To Accommodate controllers that are not only steering at front or rear
this change remove the front_steering variable from
steering_controller_library, as a byproduct of that the notion of
front or rear wheel radius is also removed from dependant controllers
and the library has know "traction_joints_names" and
"steering_joints_names" instead of "front_wheels_names" and
"rear_wheels_names".

Depends on:

• Fix steering controllers library kinematics #1150

[christophfroehlich]

I support the idea, thanks!

Please deprecate the old parameters and add the new ones to support both temporarily. Then we can also backport such changes.

Additionally, please add migration notes here.

[christophfroehlich]

Have you read and considered #692? Ideally, we should solve it with this PR.
I'm not sure if your proposal works for 4WD + 4x steering?

[qinqon]

Have you read and considered #692? Ideally, we should solve it with this PR.

The idea is the same, is all about generalize the steering library a little more.

I'm not sure if your proposal works for 4WD + 4x steering?

Next PR will allow that, I am thinking about extending the current ackermann instead of new controller, if you add a pair of traction and steering joints and define the instantaneus center of robot you can have this by modifyting a little the IK and odometry. Also you can keep the current ackermann by configuring the instantaneus centor or robot at the traction joints and using the same IK and odometry.

[mergify]

This pull request is in conflict. Could you fix it @qinqon?

[qinqon]

Tests working

$ colcon test 
Starting >>> steering_controllers_library
Finished <<< steering_controllers_library [0.44s]          
Starting >>> ackermann_steering_controller
Starting >>> bicycle_steering_controller
Starting >>> tricycle_steering_controller                                                                    
Finished <<< bicycle_steering_controller [1.50s]                                                                                                   
Finished <<< ackermann_steering_controller [1.58s]                                                            
Finished <<< tricycle_steering_controller [1.52s]

Summary: 4 packages finished [3.01s]

[mergify]

This pull request is in conflict. Could you fix it @qinqon?

[bmagyar]

@destogl please add your take

[qinqon]

@destogl I have rebase the PR, the idea is to prepare a PR based on this one to allow four steering at the ackerman controller.

[codecov]

Codecov Report

Attention: Patch coverage is 80.26316% with 30 lines in your changes missing coverage. Please review.

Project coverage is 80.32%. Comparing base (c08bdab) to head (4710c60).

Files with missing lines	Patch %	Lines
...g_controller/src/ackermann_steering_controller.cpp	25.00%	8 Missing and 4 partials ⚠️
...ing_controller/src/bicycle_steering_controller.cpp	33.33%	4 Missing and 2 partials ⚠️
...llers_library/src/steering_controllers_library.cpp	80.00%	4 Missing and 2 partials ⚠️
...ng_controller/src/tricycle_steering_controller.cpp	40.00%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1166      +/-   ##
==========================================
- Coverage   80.36%   80.32%   -0.04%     
==========================================
  Files         105      105              
  Lines        9389     9393       +4     
  Branches      827      827              
==========================================
  Hits         7545     7545              
+ Misses       1571     1569       -2     
- Partials      273      279       +6     

Flag	Coverage Δ
unittests	80.32% <80.26%> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...roller/test/test_ackermann_steering_controller.cpp	100.00% <100.00%> (ø)
...roller/test/test_ackermann_steering_controller.hpp	86.59% <100.00%> (ø)
.../test_ackermann_steering_controller_preceeding.cpp	100.00% <100.00%> (ø)
...ntroller/test/test_bicycle_steering_controller.cpp	100.00% <100.00%> (ø)
...ntroller/test/test_bicycle_steering_controller.hpp	83.75% <100.00%> (+0.63%)	⬆️
...st/test_bicycle_steering_controller_preceeding.cpp	100.00% <100.00%> (ø)
...library/test/test_steering_controllers_library.cpp	100.00% <100.00%> (ø)
...library/test/test_steering_controllers_library.hpp	96.87% <100.00%> (ø)
...troller/test/test_tricycle_steering_controller.cpp	100.00% <100.00%> (ø)
...troller/test/test_tricycle_steering_controller.hpp	85.22% <100.00%> (+0.16%)	⬆️
... and 5 more

... and 3 files with indirect coverage changes

[ARK3r]

@christophfroehlich I have a suggestion for arbitrarily long robots with an arbitrary number of traction and steering wheels in each "row". So for example if we have the following setups:

• bicycle setup 1: 2 rows, one row has a steerable wheel, second row has a traction wheel with the distance between row1 and row2 equal to 1.0 meter (wheelbase)
• bicycle setup 2: 2 rows, one row has a steerable and traction wheel, second row has a steerable and a traction wheel with the distance between row1 and row2 equal to 1.0 meter (wheelbase)
• 6 wheel rover (6-wheel rover controller #1243): 3 rows, row1 has two steerable wheels, row2 only has two steerable + traction wheels, row3 has 1 steerable + traction wheel with (1) row1 having a track of 40 cm and (2) row1 and row2 having a distance of 50 cm (wheelbase) and (3) row2 having a track of 30 cm and (4) row2 and row3 having a distance of 20 cm (wheelbase) and (5) row3 having only one wheel.

Then the way each of these can be relayed to the controller could be as follows:

a list (an arbitrarily long number of rows) of lists (info for each row) of two lists and two doubles (steerable joints list, traction joints list, this row's track double, distance of this row to the previous row double) 🫠 where each row's list contains the following info:

[ 
   <list of steerable joints in this row: List>,
   <list of traction joints in this row: List>,
   <row track: Union[None, double]>,
   <wheelbase from prev row: Union[None, double]>
]

so examples of this would be:

• bicycle setup 1:

[
   [
      ["row1_steering_joint"],
      [ ],
      None,
      None
   ],
   [
      [ ],
      ["row2_traction_joint"],
      None,
      1.0
   ]
]

• bicycle setup 2:

[
   [
      ["row1_steering_joint"],
      ["row1_traction_joint"],
      None,
      None
   ],
   [
      ["row2_steering_joint" ],
      ["row2_traction_joint"],
      None,
      1.0
   ]
]

• 6 wheel rover:

[
   [
      ["row1_left_steering_joint", "row1_right_steering_joint"],
      [],
      0.4,
      None
   ],
   [
      ["row2_left_steering_joint", "row2_right_steering_joint" ],
      ["row2_left_traction_joint", "row2_right_traction_joint"],
      0.3,
      0.5
   ],
   [
      ["row3_steering_joint" ],
      ["row3_traction_joint"],
      None,
      0.2
   ]
]

EDIT: Alternatively, for more readability, something like robot_localization's handling of multiple sources of a single message type (like IMU here) can be implemented for row1, row2, ....

[christophfroehlich]

@ARK3r I'm not sure if this is the right place to discuss this (but it would make this PR here obsolete) Let's discuss this in #692