Skip to content

Added package for steer_drive_controller.#289

Closed
MoriKen254 wants to merge 28 commits intoros-controls:kinetic-develfrom
MoriKen254:add-steer-drive-controller-kinetic
Closed

Added package for steer_drive_controller.#289
MoriKen254 wants to merge 28 commits intoros-controls:kinetic-develfrom
MoriKen254:add-steer-drive-controller-kinetic

Conversation

@MoriKen254
Copy link
Copy Markdown
Contributor

@MoriKen254 MoriKen254 commented Jul 18, 2017

I developed steer_drive_controller for 4 wheel autonomous robot, which is made based on the concept of diff_drive_controller. Thus I would like this package to be one of official ros_controllers to contribute research on autonomous driving.

The following video shows demonstration of our robot with the controller on Gazebo. We actually succeeded in driving the real robot and won a competition in Japan. More information on the robot is described on http://wiki.ros.org/Robots/CIR-KIT-Unit03.

steer_drive_controller_kinetic_demo

Detailed documentation is currently posted on http://wiki.ros.org/steer_drive_controller. Test codes passed on industrial_ci system on https://github.com/CIR-KIT/steer_drive_ros.

We also provide whole sample system where steer_drive_controller works properly. The important repository is http://wiki.ros.org/cirkit_unit03_apps. If you want to check functionality of the controller on Gazebo, please try the following commands on your PC.

(in your workspace)
$ git clone -b kinetic-devel https://github.com/CIR-KIT-Unit03/cirkit_unit03_apps
$ cd cirkit_unit03_apps
$ sh install.sh

The script resolves all dependencies properly. Then please launch the following autorun file after catkin_make.

$ roslaunch cirkit_unit03_autorun autorun_gazebo.launch

Then the world shown on the Youtube video is supposed to appear and ready for navigation, which means 2d nav goal from RViz is available.

This is my first time for pull request so I might have made mistakes on license and author stuff. For instance, I just added my name as an author to each code I modified, which was originally from diff_drive_controller. I was not sure if this way was correct. This is my first trial to request so please let me know if I did a wrong thing.

I hope I could contribute to enhancement of ros_controller by this.

Best regards.

@graiola
Copy link
Copy Markdown
Member

graiola commented Jul 18, 2017

Hello,

Thanks for the contribution!
I don't know if you noticed, but there is already an open pull request to add a four wheels steering controller (see #280).
I suggest to join the efforts with @vincentrou to see what are the similarities and the differences between the two controllers so that we don't have duplicated pull requests.

@MoriKen254
Copy link
Copy Markdown
Contributor Author

Thank you for your reply.

Oh, excuse me. I didn't notice the similar one was already going on.

Ok, I'm glad to join the effort of #280 with @vincentrou to solve current problems they are working on. Moreover, I'm gonna check and compare both packages and try to merge them into just one pull request.

@bmagyar
Copy link
Copy Markdown
Member

bmagyar commented Jul 19, 2017

Amazing, thanks guys! Having the two controllers merged would be great!

@MoriKen254
Copy link
Copy Markdown
Contributor Author

MoriKen254 commented Jul 19, 2017

@graiola @bmagyar

Thank for your response!

Main difference between controller of #280 & one of #289

I deeply looked inside of four_wheel_steering_controller by @vincentrou (#280), and found a big difference from steer_drive_controller on this request (#289). Please have a look at the following figure.

difference

In conclusion, target application robot might be different each other.

In detail

four_wheel_steering_controller by @vincentrou uses 4 position interfaces and 4 velocity interfaces because it assumes each wheel has both steer and wheel joint actuators. It seems to be applicable for rovers.

On the other hand, steer_drive_controller which I developed uses only one position interface and one velocity interface because it assumes to handle a general car-like mobile robot mechanism which consists of an ackermann link for steering and a differential gear for rear wheel driving. (sorry it hasn't been compatible with ackermann_msg yet, meaning it only recieves geometry_msgs::Twist for now, but I can add it soon if needed.)

Actually, we had to use this configuration to apply it to our real car-like robot. When we used Gazebo, we resolved a closed link problem by creating a specific RobotHWSim class. We decided to take this configuration in order to make it be able to be used more generally for various car-like robots. Please refer http://wiki.ros.org/steer_bot_hardware_gazebo for detailed documentation about this concept.
(The robot in the Youtube video on first comment of this request uses this function actually.)

Thus, I came to believe a target robot of #280 & that of #289 might be different so I beg your suggestion.

What would we do?

Now, I think there are two ways to solve this issue.

  1. merge Add four_wheel_steering_controller #280 & Added package for steer_drive_controller. #289 into single controller and switch functionality by a parameter
  2. separate Add four_wheel_steering_controller #280 & Added package for steer_drive_controller. #289 controllers

The first one can reduce the number of controller packages while codes in the package might be complicated.

The second one will increase the number of controller packages while codes in each package would be simpler. I feel this way makes cohesion higher because the target robot differs.

Which would you think is better? Or is there another better solution?

@vincentrou
Copy link
Copy Markdown

vincentrou commented Jul 21, 2017

Thank you for this detailed comparison.
Yes in fact, our packages are quite different.
I do not think that we can merge it since one is controlling 8 joints and the other 2 joints.

There is two ways for me :

  1. separate Add four_wheel_steering_controller #280 & Added package for steer_drive_controller. #289 controllers (as you said)

  2. use the four_wheel_steering_controller instead of the steer_drive_controller :

    • the real robot base controller can use the 2 rear speed and 2 front steering to command the robot
    • the real robot base controller can fake the 8 joints base on his rear speeds and front steering
    1. the pros :
    • the command can always have the rear steering to 0 and you will have the same turning behavior
    • no need to have an other controller for gazebo
    1. the cons :
    • extra computation for the real robot since 8 joints will be computed instead of 2
    • extra computation for the simulated robot since 8 joints will be computed instead of 4

@MoriKen254
Copy link
Copy Markdown
Contributor Author

MoriKen254 commented Jul 22, 2017

@vincentrou
Thanks for your suggestion!

Your second idea looks great. It'll cover more various configurations.

I wanna check one thing on that idea. As you said the real robot base controller can't take a rear speed and a steer position command. Maybe the controller must convert 2 rear speed and 2 front steering commands into one rear speed and one front steering respectively. The flow converting two commands into one seems somewhat strange for me.

170722_check

Then I have another idea. How about creating another class such like JointIFManager so that we can merge both of our requirement? Yes, I've come to think about possibility of merging inspired from your second idea.

The following figure shows my current idea about modified class diagram.

170722_new_configuration

  • As you talked in Add four_wheel_steering_controller #280, I firstly assumed there is WheelDriveController abstract super class having common SpeedLimiter with implementation.
  • WheelDriveController has two abstract classes Odometry and JointIFManager.
  • JointIFManager handles joint command conversion related processes.
  • DiffDriveController and FourWheelSteeringController inherits WheelDriveController and uses sub classes of Odometry and JointIFManager according to each functionality.
  • FourWheelSteeringController uses two types JointIFManager.
    • FourWheelSteeringJointIFManager has a role same as you mentioned.
    • CarLikeSteeringJointIFManager has a role to handle general car-like robot as I've been mentioning.
    • The two functions will be switched by a parameter.

Yes, this is NOT just merging #280 & #289 into one code but enables both rover-like function and car-like function to coexist with keeping separated each other.

More than welcome comments.

@vincentrou
Copy link
Copy Markdown

I am not sure it is a good idea to make multiple controller coexisting in the same code.

My idea was to use the four_wheel_steering_controller as it is now for your car-like vehicle.
You can use the four_wheel_steering_controller without modification but in your real robot node you need to convert the 4 velocity and position to your 1 velocity and front position.
In gazebo there is nothing special to do.
But you will need an urdf with 4 position and 4 velocity joint.
Here is an attempt to draw it :

On the real robot
ackermann_to_4ws_real

In simulation :
ackermann_to_4ws_simu

@MoriKen254
Copy link
Copy Markdown
Contributor Author

@vincentrou
Sorry for late reply. As you mentioned, our controllers have a different concept each.
I agree with your comment on #280.

Maybe we can share some super class like this. (will be different in exact)

@bmagyar bmagyar requested a review from efernandez September 4, 2017 12:50
@bmagyar
Copy link
Copy Markdown
Member

bmagyar commented Sep 4, 2017

Thank you guys, you are awesome to have posted all the analysis.

Please bear with us while we review your pull requests.

Comment thread steer_drive_controller/CHANGELOG.rst Outdated
@@ -0,0 +1,79 @@
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file should be removed

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed

Comment thread steer_drive_controller/CMakeLists.txt Outdated
project(steer_drive_controller)

find_package(catkin REQUIRED COMPONENTS
controller_interface
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please sort these dependencies

(in vim you can do it by selecting these lines in visual mode and :sort )

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed

Comment thread steer_drive_controller/CMakeLists.txt Outdated
INCLUDE_DIRS include
LIBRARIES ${PROJECT_NAME}
CATKIN_DEPENDS
roscpp
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please sort these dependencies
(in vim you can do it by selecting these lines in visual mode and :sort )

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed

Comment thread steer_drive_controller/README.md Outdated

Controller for a steer drive mobile base.

## 仕様
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use English, I'd love to learn Japanese but I feel this is not the right place or time for it :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, I'm so sorry. I forgot to remove Japanese stuff from here. I added a link to the English ROS Wiki page currently :)

* \brief The Odometry class handles odometry readings
* (2D pose and velocity with related timestamp)
*/
class Odometry
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this Odometry class different from the original one from the diff_drive_controller, if yes, how?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is. In odometry.cpp, update() method follows car-like steer drive kinematics.

namespace steer_drive_controller
{

class SpeedLimiter
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this class different from the original one from the diff_drive_controller, if yes, how?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it isn't. SpeedLimitter class is same as the diff_drive_controller's one.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you include it from there?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{
// constants
private:
enum INDX_WHEEL {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't find a reference to these indices anywhere. It's also bad practice to rely on positions in arrays.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll remove INDX_WHEEL indices. Could you please which way is better to specify positions without arrays? I would like to follow a better way if possible.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The general practice where you'd use arrays is when you have something global or semi-global storing all the data and then parts of the code "magically know" which index they need. A practice that limits the scope of functions is passing handles to data a given function needs to have access to. I'm not sure this directly applies here, as in this case the issue I raised was that there's simply no reference to those enum indices :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in MoriKen254@4abe230.

Comment thread steer_drive_controller/package.xml Outdated
<license>BSD</license>

<url type="bugtracker">https://github.com/CIR-KIT/steer_drive_ros/issues</url>
<url type="repository">https://github.com/CIR-KIT/steer_drive_ros.git</url>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these links should be updated

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed

@bmagyar
Copy link
Copy Markdown
Member

bmagyar commented Sep 26, 2017

A general but important note that I forgot to add:
we need to think about naming. We are going to have four_wheel_steering_controller which is pretty explicit in what is does. Do you think we could rename yours to something along the lines of ackermann_steering_controller?

@bmagyar
Copy link
Copy Markdown
Member

bmagyar commented Jan 11, 2018

ping @MoriKen254

@MoriKen254
Copy link
Copy Markdown
Contributor Author

@bmagyar

Thank you very much for pinging me.
Excuse me. Please give me a time. I'll do my best from now!

bmagyar and others added 5 commits April 26, 2018 08:22
The test still fails for some reason, but at least it
compiles now.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
@MoriKen254
Copy link
Copy Markdown
Contributor Author

@bmagyar

Sorry for making you wait for a long term (which is because of my very private reason though...). I've been thinking about this request during the term and now I'm ready to follow your review.

Please give me another chance and let me resume this request to be completed.

@MoriKen254
Copy link
Copy Markdown
Contributor Author

Fixed @bmagyar's #289 (comment) in MoriKen254@d89255a.

@bmagyar
Copy link
Copy Markdown
Member

bmagyar commented Aug 20, 2018

@MoriKen254 Glad you are still around!

Sorry to be a pain but could you please rebase this Pull Request on the latest melodic-devel?
This should resolve the current conflicts. I find it odd that we have conflicts on changelogs and package.xml-s...

@MoriKen254
Copy link
Copy Markdown
Contributor Author

Thank you for your response! Glad too still your welcoming this request.

So sorry on the conflicts. it's my fault. I just actually wanted to merge into the newest ver. of kinetic-devel first...

Please let me create another pull request to sum up all reviews here for now into a single commit safely and cleanly. I have got confused about the branch of mine... Sorry about that.

#356

Please let me know if this causes problems.

@mathias-luedtke
Copy link
Copy Markdown
Contributor

merged #356

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants