-
Notifications
You must be signed in to change notification settings - Fork 525
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
We need mobile base controllers #55
Comments
My personal experience with Ackermann navigation is limited to a single no-longer-operational vehicle. From reviews and discussions conducted by the ROS Ackermann Group, I believe the ackermann_msgs definitions are sufficiently general for any four-wheeled vehicle steering only with the front wheels. Some three-wheel vehicles would probably work, too. I am encouraged to see the recent announcement of wunderkammer-laboratory/ackermann_vehicle, a new Gazebo-based simulation for Ackermann drive vehicles. Integrating Ackermann steering into the standard ros-planning/navigation packages appears challenging. I doubt that planning in the configuration space of an Ackermann vehicle fits neatly into their current implementation. |
Is there a difference between omnidirectional and holonomic? I think ROS navigation already handles that for PR2 support. |
The main difference I have found between omnidirectional and holonomic is that holonomic has a more precise definition (http://en.wikipedia.org/wiki/Holonomic_%28robotics%29). One might consider a differential drive base or a base with two sets of orthogonal wheels to be omnidirectional, because the base can travel in any direction, if you don't consider orientation to be part of the definition of omnidirectional. This paper (http://ftp.mi.fu-berlin.de/Rojas/omniwheel/00509272.pdf) states that omnidirectional bases with four steerable wheels are not holonomic. The author might be using the strict definition of "holonomic," in which case the base must have exactly three actuators for three degrees of freedom. A base with eight actuators would be redundant instead of holonomic (http://www.robotplatform.com/knowledge/Classification_of_Robots/Holonomic_and_Non-Holonomic_drive.html). ROS navigation handles holonomic and non-holonomic bases. A holonomic base must be able to control its velocities along x and y separately from its angular velocity around z. A non-holonomic base must be able to control is angular velocity around z, but (this is my understanding, I haven't tried it) needs to control its velocity only along x. These coordinates are in the base_link frame. |
"single joint controllers + translation node" is how I'm controlling the base of my Cerberus robot. The node (base_ctrlr.py) subscribes to cmd_vel (a Twist message) and publishes to three steering and three axle command (Float64) topics. The system would be cleaner if the node were turned into a controller, but I have the following reservations:
An Ackermann controller would generalize well to multiple platforms. It would basically be like my ackermann_controller.py node, but less Gazebo-centric. By default, such a controller would receive commands from ackermann_cmd. I don't know how popular such a controller would be, however, since ROS navigation publishes Twist messages only, and isn't set up for bases that can't turn in place. Most omnidirectional bases could be covered by three controllers: steered-wheels (two or more individually-steered wheels), three-omniwheels, and four-Mecanum-wheels. By default, these controllers would receive Twist messages from cmd_vel. |
Thanks for all the feedback. Some further comments below:
The
I'm not familiar with
This is not so much about integration with the ROS navigation stack, but about providing controllers that allow you to use higher-level navigation functionality out of the box (like the ROS navigation stack, or an Ackermann-specific one, or...). It's about exposing A non-navigation example we're currently working on: If you have a |
I'm begun writing a base controller, and I'm confused. Here is how my controller is supposed to work: Input:
Output:
The Gazebo scenario is simple, because all the joints are effort-controlled. When using real hardware, however, the steering joints will be position-controlled and the axle joints will be velocity-controlled. I've been looking at the joint_trajectory_controller source code as an example, but I don't see how the class inheritance system allows a controller to control position-controlled and velocity-controlled joints simultaneously. In the general case, there might also be effort-controlled joints, e.g. the front steering joint might use a motor driver instead a motor controller, in which case its PID loop would have to run in software. |
Is there a public example of interfacing a controller manager with hardware? I've considered following the model used in dynamixel_motor (http://wiki.ros.org/dynamixel_motor), in which there is a dynamixel_mgr node that acts as the controller manager (Note: dynamixel_motor does not use ros_control). In a ros_control version, the RobotHW-derived class object that is passed to the controller manager would be a chunk of code that associates joint names with combinations of serial ports and motor numbers. The node I am considering writing would do essentially the same thing, except with Roboteq motor controllers. A downside of this approach is that it does not support controllers that need to use both Dynamixel and Roboteq controlled joints, because those joints are controlled by separate controller managers. Is the intent of ros_control that there are several controller managers, each controlling a certain type of hardware? Or is there supposed to be just one controller manager, controlling all the hardware? |
I'm getting my steered_wheel_base_controller ready to be released, but there is a problem I'm trying to fix, and I'd like some opinions about it. When the controller is initialized (i.e. in initRequest()), I need to use tf to find the positions of the wheels in the base frame. However, when the controller is running within Gazebo and /use_sim_time is true (both always true for me right now), this hangs. The problem is that tf requires a time server, but Gazebo is the time server, but it is not publishing time values because it is still initializing the gazbo_ros_control plug-in. My current work-around is to check in update() whether tf-related initialization of the controller has taken place. If not, update() returns immediately. Otherwise, tf-related initialization is attempted, and a flag is set if it succeeded. The problem with this approach is that it possibly (Probably? Definitely?) will break the real-time constraint during the update() call during which tf is used. I've been thinking of setting up a timer callback in initRequest(), called once per second. The callback will attempt tf-related initialization, calling Timer::stop() and setting a flag when initialization succeeds. The callback will be called by the non-realtime thread. Can anyone propose an alternative? |
The initRequest gets triggered by the spawner loading a controller. So this should only happen after the controller manager got started and gazebo finished loading the controller manager plugin. It might take a while for the first tf messages to arrive, but you should be able to just block in the initRequest call until the right tf messages arrive. So if your controller initialization is hanging, this points to gazebo using only using one single ros spin thread. You can get around this problem by giving your tf listener its own thread to receive tf messages. However, I'm curious to hear why you need to receive tf messages in your controller. Do you need (i) to look up a fixed transform between two frames? In that case, you can directly parse the urdf in your initRequest call to get the fixed transform. Or do you need (ii) to get the state between two frames that have a moving joint between them? In that case... you have a bunch of other problems, but before going into that it might be good to hear a bit more about your use case. |
I need to get the fixed transform from the base frame (specified by a parameter) to the steering axis of each wheel. These transforms are needed in order to compute steering angles that will point each drive axle toward the robot's center of rotation. I'm calling tf::TransformListener::lookupTransform() to get the transforms because that's how I've seen it done in all the examples I've examined. Is there some code available that works like lookupTransform(), but uses URDF data instead of tf? I can write it myself, but that sounds a problem that someone probably already solved. I didn't see anything similar to lookupTransform() in the URDF API docs. |
Okay, for that usecase using the urdf directly is definitely the right way to go. The easiest way to get something linke "lookupTransform" would be to parse the urdf into a kdl tree http://wiki.ros.org/kdl_parser, and then call the kdl api http://orocos.org/kdl to get the poses between the wheels and the base. |
@jim-rothrock Have you been satisfied with steered_wheel_base_controller? Would you consider contributing that to ros_controllers? |
I'm considering it, but will have to consult with my attorney concerning liability issues that may arise from letting parties outside of Wunderkammer Laboratory modify the code, as opposed to modifying their own forked versions. |
We have made ROS controllers for ackermann and four_wheel_steering vehicles. Do not hesitate to test it and give us feedback ! This is only for indigo for now since there is a problem to simlulate PositionJointInterface on gazebo7/kinetic |
Great!
Do you guys have videos of these controllers? Perhaps a simulation package
that brings up vehicles that we could use to try them?
If we can get some tests & documentation set up for them we could even consider adding them to `ros_controllers`.
…On 2 February 2017 at 17:26, vincentrou ***@***.***> wrote:
We have made ROS controllers for ackermann and four_wheel_steering
vehicles.
https://github.com/romea/romea_controllers
Do not hesitate to test it and give us feedback !
This is only for indigo for now since there is a problem to simlulate
PositionJointInterface on gazebo7/kinetic
ros-simulation/gazebo_ros_pkgs#479
<ros-simulation/gazebo_ros_pkgs#479>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#55 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADXH4ebxgLigU4f7LfsERP26jknsFdbsks5rYgPJgaJpZM4BD3TK>
.
|
Here is a vehicle that we use for now with those controllers : There is already some basic test to validate the kinematics equations. |
We are interested to integrate our four_wheel_drive_controller in ros-controls. |
I like the idea of adding more controllers but I'd keep them for now in Could you create a pull request where you add |
Before I submit a PR. |
|
For the For the
I have submit an issue ros-drivers/ackermann_msgs#4 on the |
Combining the messages in a single repo forces them to always be released together, with the same version numbers. Given the stability of |
Thanks for your input @jack-oquin , point taken! As for |
@jack-oquin has already create a repo in ros-drivers and I just push the package in it https://github.com/ros-drivers/four_wheel_steering_msgs @bmagyar For the |
Could we get feedback some more please? @efernandez |
@bmagyar has you said in your previous comment #55 (comment) , I can host the |
Just to confirm, the main point of this thread now is how to integrate https://github.com/Romea/romea_controllers in ros_controllers, right? I don't want to miss any other important point of discussion here, @bmagyar I see a lot of common things between the diff_drive_controller and multiple packages there, and I completely agree with getting things in and splitting some of the functionality. I'd just comment about the URDF stuff for now: Most of this was originally done for the diff_drive_controller because there is/was nothing else providing that AFAIK. For some cases like
If we create a library for this, I think the methods should A bigger change, that I wouldn't do now, would be to have something like I refrain myself from adding more comments. If you like the idea of creating a Regarding the Regarding the messages it seems they're already in |
Spot on! I really like the idea of aligning with tf and urdf types although getting it into geometry2 may prove a bit tricky. What if we start hosting |
Yes, works for me. I don't have a strong opinion on where to get things. |
|
|
https://github.com/ros-controls/urdf_utilities |
@bmagyar Do you want also to create the |
I wouldn't create a new package for a single utility function. Let's roll
with one but try to use tf2 & Eigen math tools as much as you can.
…On 28 April 2017 at 13:55, vincentrou ***@***.***> wrote:
@bmagyar <https://github.com/bmagyar> Do you want also to create the
tf2_urdf in ros-controls ? Or we leave it for now if it is just for the
euclideanOfVectors function ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#55 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADXH4QtRY_slPzaXrOpMQ_dgg9MEFZ84ks5r0eHYgaJpZM4BD3TK>
.
|
Added a param to toggle whether or not to limit accel before wheelSpe…
All,
To make the ros_controll(ers) project appealing to a larger user base, we need to offer functionality needed by that user base, and controllers are a big part of that. Currently, the list of available general-purpose controllers is still quite limited, and we have a big zero on mobile base / vehicle controllers.
I've convinced a colleague to make a diff-drive controller that should land sometime soon, but I wonder about the interest and generality of other implementations.
Interest
Does it make sense to have mobile base controllers inside the (possibly high-frequency)
controller_manager
loop, or is it enough to control individual wheels with low-level single-joint controllers?. Many navigation scenarios have relatively slow dynamics, but I can imagine many scenarios (self-driving cars!) having requirements for faster dynamics.Further, having a single ros_control plugin that takes in higher level navigation commands results in simpler deployments than single_joint controllers + an additional node for translating navigation commands to joint commands.
Generality
Implementations like the diff-drive generalize well to multiple robot platforms. Does the same apply to an Ackermann-type controller, are they easily configurable (@jim-rothrock, @jack-oquin)?. How about omnidirectional bases?, these seem more complex to generalize, is it the case?. Are there other controller types that would be of general interest?.
The text was updated successfully, but these errors were encountered: