Code Monkey home page Code Monkey logo

diff_drive's Introduction

diff_drive — Differential-Drive Controller

This package implements ROS nodes to control and monitor a differential-drive robot.

The package is intended as a lighter-weight solution than the ROS controller framework, albeit with lower performance since it is written in Python. If you need tight, real-time control, you may want to look at ros_controllers, a C++ package which includes a differential-drive controller that is integrated with ros_control and controller_manager. Those controllers are designed to integrate with hardware in the same process, rather than using topics. Instead, this package expects to publish the desired motor speeds using standard ROS messages.

Supplied Nodes

  • diff_drive_controller — Converts from twist to wheel velocities for motors.

  • diff_drive_odometry — Publishes odometry from wheel encoder data.

  • diff_drive_go_to_goal — Moves the robot to a goal position.

  • diff_drive_mock_robot — Implements a mock differential drive robot, for testing.

The nodes in this package are designed with these considerations:

  • The node and hardware implementing differential drive should deal only in encoder ticks.

  • Conversions to and from physical coordinates should happen within the nodes in this package.

  • This package should integrate cleanly with the navigation stack, perhaps with remappings.

  • Nodes should use standard topic and parameter names used by the navigation stack, but should allow remapping.

Demo

To see all the nodes in this package in action, you can launch a demo from ROS. There are no dependencies other than the standard ROS packages.

roslaunch diff_drive demo.launch

This launches rviz as part of the demo, and shows the robot position as a small coordinate system on a 0.25m grid. In rviz you can move the robot by clicking the 2D Nav Goal button in the tools panel at the top. Then click and drag within the grid to set the robot goal position and heading. The mock robot will move to that new pose, which you can see by the movement of the robot axes.

In the demo, both forward and backward movement is allowed, so if the goal position is behind the robot, it will move backward. You can force the robot to move foward only by setting the parameter ~forwardMovementOnly to true.

ROS API

1. diff_drive_controller

Listens for desired linear and angular velocity, and publishes corresponding wheel velocities, in encoder ticks per second, required to achieve those velocities.

Published Topics

~lwheel_desired_rate (std_msgs/Int32)

Desired left wheel rotation rate, in encoder ticks per second.

~rwheel_desired_rate (std_msgs/Int32)

Desired right wheel rotation rate, in encoder ticks per second.

Subscribed Topics

~cmd_vel (geometry_msgs/Twist)

Desired linear and angular velocity.

Parameters

~ticks_per_meter (double)

Number of encoder ticks per meter of travel.

~wheel_separation (double)

Distance between the two wheels (meters).

~rate (int, default: 50)

The rate that the output velocity target messages will be published (Hz).

~timeout (int, default: 0.2)

The maximum number of seconds expected between cmd_vel messages. If cmd_vel is not received before this limit, the controller will assume the commanding node has died and will set the desired wheel rates to zero, to stop the robot.

2. diff_drive_odometry

Listens for wheel movement and rates and publishes the transform between the odom frame and the robot frame.

Published Topics

~odom — (nav_msgs/Odometry)

The robot odometry — the current robot pose.

~tf

The transform between the odometry frame and the robot frame.

Subscribed Topics

~lwheel_ticks (std_msgs/Int32)

Cumulative encoder ticks of the left wheel.

~rwheel_ticks (std_msgs/Int32)

Cumulative encoder ticks of the right wheel.

~lwheel_rate (std_msgs/Float32)

Left wheel rotation rate, in encoder ticks per second.

~rwheel_rate (std_msgs/Float32)

Right wheel rotation rate, in encoder ticks per second.

Parameters

~ticks_per_meter (double)

Number of encoder ticks per meter of travel.

~wheel_separation (double)

Distance between the two wheels (m).

~rate (double, default 10.0)

The rate at which the tf and odom topics are published (Hz).

~timeout (double, default 0.2)

The amount of time to continue publishing desired wheel rates after receiving a twist message (seconds). If set to zero, wheel velocities will be sent only when a new twist message is received.

~base_frame_id (string, default: "base_link")

The name of the base frame of the robot.

~odom_frame_id (string, default: "odom")

The name of the odometry reference frame.

~encoder_min (int, default: -32768)
~encoder_max (int, default: 32768)

The min and max value the encoder should output. Used to calculate odometry when the values wrap around.

~wheel_low_wrap (int, default: 0.3 * (encoder_max - encoder_min + 1) + encoder_min)
~wheel_high_wrap (int, default: 0.7 * (encoder_max - encoder_min + 1) + encoder_min)

If a reading is greater than wheel_high_wrap and the next reading is less than wheel_low_wrap, then the reading has wrapped around in the positive direction, and the odometry will be calculated appropriately. The same concept applies for the negative direction.

3. diff_drive_go_to_goal

Listens for new goal poses and computes velocities needed to achieve the goal.

Published Topics

~distance_to_goal (std_msgs/Float32)

Distance to the goal position (meters).

~cmd_vel (geometry_msgs/Twist)

Desired linear and angular velocity to move toward the goal pose.

Subscribed Topics

~goal (geometry_msgs/Pose)

Desired goal pose.

Parameters

~rate (float, default: 10)

Rate at which to publish desired velocities (Hz).

~goal_linear_tolerance (float, default: 0.1)

The distance from the goal at which the robot is assumed to have accomplished the goal position (meters).

~goal_angular_tolerance (float, default: 0.087)

The difference between robot angle and goal pose angle at which the robot is assumed to have accomplished the goal attitude (radians). Default value is approximately 5 degrees.

~max_linear_velocity (float, default: 0.2)

The maximum linear velocity toward the goal (meters/second).

~max_angular_velocity (float, default: 1.5)

The maximum angular velocity (radians/second).

~max_linear_acceleration (float, default: 4.0)

The maximum linear acceleration (meters/second^2).

~forwardMovementOnly (boolean, default: true)

If true, only forward movement is allowed to achieve the goal position. If false, the robot will move backward to the goal if that is the most direct path.

~Kp (float, default: 3.0)

Linear distance proportionality constant. Higher values make the robot accelerate more quickly toward the goal and decelerate less quickly.

~Ka (float: default: 8.0)

Proportionality constant for angle to goal position. Higher values make the robot turn more quickly toward the goal.

~Kb (float: default: -1.5)

Proportionality constant for angle to goal pose direction. Higher values make the robot turn more quickly toward the goal pose direction. This value should be negative, per Autonomous Mobile Robots.

The control law for determining the linear and angular velocity to move toward the goal works as follows. Let d be the distance to the goal. Let a be the angle between the robot heading and the goal position, where left is positive. Let b be the angle between the goal direction and the final pose angle, where left is positive. Then the robot linear and angular velocities are calculated like this:

v = Kp * d
w = Ka*a + Kb*b

See Autonomous Mobile Robots, Second Edition by Siegwart et. al., section 3.6.2.4. In this code, when the robot is near enough to the goal, v is set to zero, and w is simply Kb*b.

To ensure convergence toward the goal, Kp and Ka must be positive, Kb must be negative, and Ka must be greater than Kp. To ensure robust convergence, so that the robot never changes direction, Ka - 5/3*Kb - 2/pi*Kp must be greater than zero.

4. diff_drive_mock_robot

Implements a simulation of perfect differential drive robot hardware. It immediately follows any speed commands received with infinite acceleration, and publishes the wheel encoder values and encoder rates.

Published Topics

~lwheel_ticks (std_msgs/Int32)

Cumulative encoder ticks of the left wheel.

~rwheel_ticks (std_msgs/Int32)

Cumulative encoder ticks of the right wheel.

~lwheel_rate (std_msgs/Float32)

Left wheel rotation rate, in encoder ticks per second.

~rwheel_rate (std_msgs/Float32)

Right wheel rotation rate, in encoder ticks per second.

Subscribed Topics

~lwheel_desired_rate (std_msgs/Int32)

Desired left wheel rotation rate, in encoder ticks per second.

~rwheel_desired_rate (std_msgs/Int32)

Desired right wheel rotation rate, in encoder ticks per second.

Parameters

~cmd_timeout (float, default: 0.2)

The amount of time after the last wheel rate message when the robot should stop automatically (seconds).

~rate (float, default 10.0)

The rate at which the simulated wheel encoder values and rates should be published (Hz).

diff_drive's People

Contributors

merose avatar plieningerweb avatar timple avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

diff_drive's Issues

Issues running demo [ROS melodic]

Hi,

I just tried to run the demo by following the README instructions after a fresh clone of your repo. Rviz launches fine but the terminal gives the following errors:

[odom_publisher-5] process has died [pid 9672, exit code 1, cmd /home/niambh/Documents/XOXO/project/diff_drive_ws/src/diff_drive/nodes/diff_drive_odometry __name:=odom_publisher __log:=/home/niambh/.ros/log/7bed8d5e-d016-11ea-aa71-4cbb5855c239/odom_publisher-5.log].
log file: /home/niambh/.ros/log/7bed8d5e-d016-11ea-aa71-4cbb5855c239/odom_publisher-5*.log
[diff_drive_go_to_goal-7] process has died [pid 9687, exit code 1, cmd /home/niambh/Documents/XOXO/project/diff_drive_ws/src/diff_drive/nodes/diff_drive_go_to_goal cmd_vel:=/robot/cmd_vel __name:=diff_drive_go_to_goal __log:=/home/niambh/.ros/log/7bed8d5e-d016-11ea-aa71-4cbb5855c239/diff_drive_go_to_goal-7.log].
log file: /home/niambh/.ros/log/7bed8d5e-d016-11ea-aa71-4cbb5855c239/diff_drive_go_to_goal-7*.log

Screenshot from 2020-07-27 16-51-55

Do you know why this could be happening?
I am using ROS melodic with Ubuntu 18.04.

Wrong formula of ''b''?

According to the Autonomous Mobile Robots book, the formula is:
b = - (cur.theta + a)
why in your code it is:
b = cur.theta + a - goal.theta

I understand the sign is changed for simpler Math but why minus the goal.theta?
By the way, I am trying to move the robot (R2D2 [http://wiki.ros.org/urdf/Tutorials/Building%20a%20Visual%20Robot%20Model%20with%20URDF%20from%20Scratch]) but the controlling part for angular velocity is really bad when the robot tries to move to a point behind it. It keeps rotating until it falls down. Do you have any suggestions?

Need minimum xVel and minimum turn-in-place thetaVel

If the proportional constants are small enough, the robot can stall before reaching the goal position or orientation. There needs to be a parameter for minimum xVel when the position is not yet achieved, and minimum thetaVel when the position is achieved but not yet the orientation.

does diff_drive do PID?

Hello,

I was looking at diff_drive as an alternative to http://wiki.ros.org/diff_drive_controller

It seems however that your software works really nice, and easier to implement then diff_drive_controller.

Is the PID done by this controller, or not? I read tru the code and I understand that PID has to be handled by the controller and in terms of encoder ticks?

In terms of comparison and the exception of PID, what could the diff_drive_controller can do that diff_drive can't?

Does this software use other libraries or systems from ros, like controllers perhaps, or is it completely self contained?

Use in real robot

Need help for use in real robot; this work is amazing; I have a lot of difficult; my rover is rover5 and use ros-motor-romeo-quad; but your mock_robot is complete perfect rover... How I can use my rover?

struggling to get this to work, what's cmd_vel x in? ticks per sec?

I'm strugging getting this working. I've copied the demo launch, commented out everything but "robot_state_publisher","joint_state_publisher","controller","odom_publisher". Started it up. Published on /cmd_vel with a maximum x of 1, and I get 0 on /rwheel_desired_rate. I thought that should produce 3000 (==max_motor_speed from the launch file) ticks per second on both left and /rwheel_desired_rate ? I've also tried publishing with large x (==10000) in case I've misunderstanding cmd_vel, but I still can't get the r value to increase. Any help appreciated. Thanks,

/odom and /cmd_vel not matching

Hi, I'm trying to setup a robot using the diff_drive controller. I believe I have my ticks per meter and my wheel seperation setup correctly.

When I compare the /odom output, the linear velocity almost matches the speed i'm sending, but the angular velocity is way off. Should this not match?

I compared the same values on the mock robot, but it didn't match either. Am I missing something fundamental ?

T

If reverse movement is enabled, does not follow shortest path

Still working on a simple way to reproduce, but using the demo launcher when publishing navigation goals poses from rviz the mock robot does not always follow the shortest path, sometimes turning around and backing toward the goal even if forward movement would be more efficient.

No problems found when limited to forward movement.

Adjust speeds based on maximum accelerations

There are parameters for maximum linear and angular acceleration but they are not yet used. This causes a noticeable lurch and possibly jerk to new orientation when the robot starts moving. Need to limit speed changes to keep under the acceleration limits.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.