-
Notifications
You must be signed in to change notification settings - Fork 523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making room for mecanum_drive_controller #147
Comments
How much of |
On a very rough estimate I would say 50%... and spread like this:
|
I would advise against further generalization of the existing diff_drive_controller code since it would introduce more complexity to something that is otherwise extremely simple. Luckily though in C++ it is possible to inherit code from a parent class. I'd suggest an approach where you introduce a dependency to diff_drive_controller, inherit code from there and override the necessary parts in your controller. Feel free to add some virtuals to whereever it's necessary in the diff_drive_controller code. |
...or see if some controller components can be factored out in separate classes / functions, so compose instead of extend. |
@arennuit What do you mean a mecanum driver controller? Do you mean an omnidirectional base using mecanum wheels, so it can move sideways? The |
@bmagyar, @adolfo-rt : no worries I do not plan to extend the diff_drive_controller but only to factor the common code out (as Adolfo is mentioning) @efernandez: yes I mean a controller which computes mecanum wheels velocities given a desired mobile base twist and also computes the odometry I am currently putting together some code completely separate from diff_drive_controller (but unshamingly based on it ;)). Then we can review it and decide where to go. |
I have a basic implementation working but currently it is assuming the input twist (topic cmd_vel) is a body velocity and the computed odometry velocity is also "body". Can you confirm? I have not been able to find the answer by simply reading documents about the navigation stack... This relates to this question : http://answers.ros.org/question/196233/geometry_msgstwist-references-navigation-stack-ros_control/ |
I have created a related PR: #149 |
In the end you have to make an assumption on the frame of the input twist, and yes, you can interpret this as "body". The computed odometry I believe is always "body" by convention. Be prepared though, you will have a hard time to convince me about the necessity of factoring out parts of the diff_drive_controller. |
@bmagyar I still need to review your point on factoring code out, but I must admit the 2 controllers share less code than I initially thought |
@efernandez thanks for your input ;) |
I believe this code is starting to be in a usable state. Still needs further testing, unit tests (none written so far) and code review. |
Hi guys,
I am currently developping a mecanum_drive_controller which (as its name states) will take a twist as input and generate desired wheel velocities. From what I have seen this class will be rather close to diff_drive_controller. So I was thinking of factoring the common code out into a drive_controller class (from which diff_drive_controller and mecanum_drive_controller would derive). It does not look like a big issue, but I was wondering how you would welcome this proposition... If you consider its worth the effort, then I'll make a proposition in a fork of mine, otherwise no worries I'll do a completely separate package in a repo of mine.
Just let me know what you think.
Thanks,
Antoine.
The text was updated successfully, but these errors were encountered: