Differential Drive

Glossary Item Box

Robotics Common: Robotics Common Overview

Microsoft Robotics Developer Studio

Send feedback on this topic

Differential Drive

The Generic Differential Drive service defines how to control a two-wheeled robot.

This sample is provided in the C# language. You can find the project files for this sample at the following location under the Microsoft Robotics Developer Studio installation folder:

Samples\Common

Contents:

• Background
• Setup Requirements
• Operations
• Notifications
• Reference Implementation
• Related Services

Prerequisites

Hardware

This sample requires no special hardware because it is a generic contract and is not designed to run directly on hardware.

Software

This service is designed for use with Microsoft Robotics Developer Studio.

Background

A differential drive usually consists of two wheels that can be driven independently. However, this concept can be applied to other forms of locomotion such as legged robots, like a hexabot with three legs on each side. A key feature of a differential drive is that by driving the wheels in opposite directions the robot can rotate on the spot.

The Generic Differential Drive (GDD) contract consists of service state and operation definitions, which in this case are DriveState.cs and DriveTypes.cs. The GDD is designed to partner with motor services and (optionally) wheel encoder services. All robots that conform to the GDD contract can be controlled by applications that ship with RDS, such as the Simple Dashboard, because the GDD provides a common specification for the programming interface.

The GDD contract should be used to implement hardware-specific GDD services. RDS provides a command line tool (called DssNewService) and a Visual Studio wizard that can be used to create a service that implements an existing contract.

The GDD is unusual because an actual implementation of the service is provided with RDS in Drive.cs. (Generic contracts usually do not have a real service, just service state and type definitions). This is discussed below under Reference Implementation.

Several implementations of the GDD are included with RDS for different robot hardware and also for the Simulator. The discussion that follows frequently refers to "the robot". This means the implementation of the GDD on a particular robot. See the Service Tutorials for information on how to write services that implement alternate contracts such as the GDD.

Setup Requirements

The GDD is included in RoboticsCommon. You need to add a reference to RoboticsCommon.Proxy to your project if you want to use the GDD.

Configuration

Although a GDD can have a configuration file, this is not required for some implementations.

Operations

The complete service description for the GDD is available in the Service Description Index which can be opened from the RDS start menu.

Additional information is provided below that elaborates on the service description.

AllStop

In an emergency you can issue an AllStop request to the GDD. This will cancel any operation in progress and set the power to both wheels to zero. For safety reasons, the drive will be disabled. Before you can drive the robot again you must call EnableDrive with the parameter set to true. Until you have re-enabled the drive, all other requests will fail and return a Fault.

All robots should support this operation.

EnableDrive

The EnableDrive operation accepts a single parameter which is a boolean. It can be used to enable (parameter set to true) or disable (parameter set to false) the drive. Initially the drive should be enabled. When it is disabled, all requests to move the robot will fail. Also, if the drive is disabled while it is running then it should immediately stop regardless of what type of operation is being performed.

SetDrivePower

SetDrivePower accepts power settings for the left and right wheels as values between -1.0 and 1.0 (doubles). Negative values mean that the wheel should rotate backwards, and positive values mean the wheel should rotate forwards.

Successive SetDrivePower requests can be used to vary the motor powers and achieve complex driving patterns. Each new request simply changes the power applied to the motors and supersedes the previous request.

Setting a value of zero for both wheels means that the robot should stop. Be aware, however, that some robots might "coast" for a little while before stopping after driving at high speed. By applying equal power to both wheels but with opposite signs a two-wheeled robot can be made to rotate on the spot.

There might not be a direct relationship between the power settings and the speed of the robot, i.e it is not required to be linear. The only requirement is that larger (absolute) values should make the motors run faster. There might be some point less than 1.0 where the motors reach their maximum running speed. Some robots might only support a discrete set of power levels, and it is even possible for the motors to only have two levels: off (stopped) or on (running).

Due to the characteristics of real motors it is possible that small values of power, e.g. 0.1, might not be sufficient for the robot to move. Conversely, using a value of 1.0 might result in the robot moving very fast. You should establish the behavior of your particular robot in response to power settings during initial testing.

For robots that do not have a two-wheel drive, these power settings can be interpreted to mean the left-side power and the right-side power for whatever the method of locomotion might be.

SetDriveSpeed

The SetDriveSpeed operation is intended to set the speed of the drive in meters per second. However, many robot services do not implement this operation. The reason is quite simple - it is not possible to accurately calculate speed. The speed of a robot depends on its geometry (such as wheel radius), the relationship of power to the rotational speed of the motors and possibly the battery voltage level. Because of all these factors, it is not possible to control the actual speed of the robot except on the more expensive models.

To accurately control speed, it is also necessary to have some feedback from the wheels. This information is usually provided by wheel encoders. Then a control algorithm, such as PID (Proportional, Integral and Derivative) control. For performance reasons, this should be implemented on the robot.

DriveDistance

The DriveDistance operation is used to move the robot forwards or backwards by a specified distance in meters.

The DriveDistance operation is not implemented by all drive services because it requires encoders on the wheels. Some services might implement this operation using a timer to approximate the motion. (This is the recommended approach so that other services do not fail if they try to use this operation). However, this might not be very reliable.

There are three parameters: Distance; Power; and DriveDistanceStage. The Distance must always be a positive (double) value in meters. The Power is specified using the same convention as the SetDrivePower operation, i.e. between -1.0 and 1.0 with negative values meaning to move backwards.

The DriveDistanceStage must be initialized when you make a request using the value DriveStage.InitialRequest. This field is updated when notification messages are sent be the GDD service. See the explanation of Notifications below.

If you do not initialize the DriveDistanceStage the default value should be equivalent to DriveStage.InitialRequest. However, it is good practise to set the value explicitly. Failure to do so could result in the request not being accepted.

Issuing any other motion request to the drive (including another DriveDistance) should cancel a DriveDistance that is already in progress. However, some robots might be unable to cancel these requests. This is hardware-dependent.

RotateDegrees

The purpose of RotateDegrees is to rotate the robot on the spot by a specified angle. Angles are in degrees (as implied by the name) with positive angles meaning left or anti-clockwise with respect to the center of the robot as viewed from above.

The RotateDegrees operation is not implemented by all drive services because it requires encoders on the wheels. Some services might implement this operation using a timer to approximate the motion. (This is the recommended approach so that other services do not fail if they try to use this operation). However, this might not be very reliable.

There are three parameters: Degrees; Power; and RotateDegreesStage. The purpose of the first two is obvious. The RotateDegreesStage must be set to DriveStage.InitialRequest when you send a request. This field is updated when notification messages are sent be the GDD service. See the explanation of Notifications below.

If you do not initialize the RotateDegreesStage the default value should be equivalent to DriveStage.InitialRequest. However, it is good practise to set the value explicitly. Failure to do so could result in the request not being accepted.

Robots are not guaranteed to turn by exactly the specified angle, and there is no requirement to support angles greater than 360 degrees. The accuracy of the rotations will vary from one robot to another depending on the hardware. Lower power settings should result in more accurate turns, but some robots might stall if you set the power too low and never complete the rotation.

Issuing any other motion request to the drive (including another RotateDegrees) should cancel a RotateDegrees that is already in progress. However, some robots might be unable to cancel these requests. This is hardware-dependent.

ResetEncoders

The ResetEncoders request can be used to set both of the wheel encoders back to zero. The current encoder values are available from the Wheel State which is part of the GDD State.

All robots that have wheel encoders should support this operation.

Notifications

You can subscribe to the GDD to receive notification messages when operations take place.

Update

The Update notification contains the new state of the GDD service, which includes information about the motors. From this you can determine whether the drive is moving or not.

Controlled Motions

The next two notification types, DriveDistance and RotateDegrees, work in a similar way to each other. Both of these operations send back a response immediately, but then follow up with notifications. The notification messages are the same data type as the request messages, with the important difference that the DriveDistanceStage or RotateDegreesStage fields are updated to show the progress of the operation.

In the simplest case, the drive starts the requested motion and then completes it some time later. This is shown diagramatically for a DriveDistance request in the Figure below.

Notifications - Standard Completion

If a DriveDistance or RotateDegrees is interrupted because another drive request is received before the operation has completed, then the sequence of notifications is different. In this case the first operation is canceled and the second one is executed as usual. Note that any motion request, not just one of the same type, will cause an operation currently in progress to be canceled.

The following Figure shows one DriveDistance interrupting another one. Although it shows two services, A and B, it could be the same service making the requests based on sensor input.

Notifications - Operation Canceled

Rotate Degrees

When you issue a RotateDegrees request, the GDD sends back a response message immediately (unless there is a Fault). It then issues a "Started" notification when the command is initiated on the robot.

Once the rotation has finished, a "Completed" notification will be sent.

If RotateDegrees is interrupted by another motion request, a "Canceled" notification will be sent.

The way that requests are handled can vary from one robot to another and depends on the service implementation. As a result, it is possible for a new "Started" notification to arrive before a "Canceled" notification.

Drive Distance

When you issue a DriveDistance request, the GDD sends back a response message immediately (unless there is a Fault). It then issues a "Started" notification when the command is initiated on the robot.

Once the robot has moved the requested distance, a "Completed" notification will be sent.

If RotateDegrees is interrupted by another motion request, a "Canceled" notification will be sent.

The way that requests are handled can vary from one robot to another and depends on the service implementation. As a result, it is possible for a new "Started" notification to arrive before a "Canceled" notification.

Reference Implementation

A sample implementation of the Generic Differential Drive contract is provided with RDS. This can be used to control a real robot if it implements Motor services by creating an appropriate manifest that partners the motors with the GDD.

If you implement a motor service for your robot, then you can use the sample GDD service to control it without having to write your own GDD service. Instead you write a motor service which is much simpler. To use the GDD service you create a manifest that partners with two motor services. The motor services are hardware-specific, but the GDD service is not. This provides developers with a quick path to getting a new robot working.

It is possible to implement the GDD contract without using motor or encoder services. In this case, the GDD service talks directly to the robot's wheels, possibly via a "brick" service. Other services that partner with the GDD do not need to know how it controls the wheels and should not care if there are motor services. The sample GDD does not do this because it requires a hardware-specific interface.

The sample GDD implements a web interface for controlling the drive. This is done using embedded XLST to display the web page. A HttpPost handler processes requests from the web page. The figure below shows what this page looks like.

This page is displayed when you browse to the GDD service running on a DSS node. This is intended as an example of how to use use the automatic translation of web requests into DSSP operations. Although this sample page is accessed from within the DSS environment, it is possible to write completely separate web pages to perform the same functions and post messages to the service. No JavaScript code is required to format the request, unless you want to validate the parameters before sending.

Related Services

The Simulated Differential Drive is based on the Generic Differential Drive contract.

A Simulated Four By Four Drive is also available with RDS. It is quite different to the Generic Differential Drive and does not conform to this contract.

Refer to VPL Hands On Labs for examples of using DriveDistance and RotateDegrees. These labs can be run using the Simulator so that you can learn about the GDD without a real robot.

See Also

Robotics Common: Robotics Common Overview

 

 

© 2012 Microsoft Corporation. All Rights Reserved.