API Documentation & Variable Drive parameters

[vmandke]

Need help understanding the APIs of drive and variable drive. From the examples it seems that both drive and variable drive move forward the robot a certain distance. This distance moved is then provided via the callback travelDataDidUpdate. However, I would like to have better control and accuracy with the robot movement ( +/- 2 inches )

Currently

doubleDriveShouldUpdate {
      if (distanceToCover > some_random_threshold_inches) {
              do variable drive of drive=self.drive, turn=0
      } else {
             stop drive
      }
}

doubleTravelDataDidUpdate {
      distanceToCover -= dr_double_instance.xDeltaInches
}

Above is a minimal pseudo code of what I am doing. However as the callbacks are a bit delayed the robot overshoots by almost 1.6 inches per 10 inches of travel, on an average. (on smaller distances the travel is unpredictable) This is almost overshoots when travelling longer distances of 300 inches or so.

Exactly what does the drive param of variableDrive / drive specify?
How delayed can these callbacks for distance travelled be ?
What should the some_random_threshold_inches be set to ?

I was unable to find detailed documentation for the API. Can you please point me to it ?

Exactly what does the drive param of variableDrive / drive specify?

The SDK sends a constant stream of drive commands to the base over Bluetooth (~5 times per second), when one of the drive or turn values is non-zero. This is to ensure that the base can automatically stop, if it fails to receive drive commands due to some error or other interference.

How delayed can these callbacks for distance travelled be ?

Travel data is sent ~10 times per second from the base to the iPad over Bluetooth.

What should the some_random_threshold_inches be set to ?

This depends on your application, of course. Your note about 1.6" difference when attempting to travel by 10" is not unexpected. The system is not designed for repeatability of exact driving distances, especially in very small distances. There are many factors in the balancing and driving algorithm that affect the system, including external factors, such as weight distribution, floor levelness, and floor surface texture, so the system is designed to automatically adapt to different environments, which is a different design goal than repeatability. You can probably get more accuracy by driving slower (using variableDrive closer at 0.5 or less), since you'll have more resolution in reading the travel data and time to stop.

The travel data feedback should be the most reliable data (rather than time of driving command), so I would suggest making your algorithm adapt to actual distances traveled over time (i.e. adding up the vectors) rather than assuming that each step must hit its target exactly.

If you can describe your overall project goal in more detail, we'd be happy to suggest the best way to use the Double SDK to help achieve your goals. Feel free to email support@doublerobotics.com, if you'd like to discuss offline.

[vmandke]

Thanks for the quick reply. I just need to understand the drive param of the API variableDrive a bit more.
I am trying to build autonomous indoor navigation using DoubleRobot. However, as this is within confined small spaces we need to be quite accurate with how much the robot travels so that it can also pass through doors and areas between walls and beams.

When a drive command with drive = 1 is given, to the base what exactly does this mean ? Does this mean a one full revolution of the wheel in forward direction which is then subsequently translated into smaller steps by the base? Am I then correct in assuming that the above pending steps will be cancelled if a STOP is sent ?

Consider a scenario in which it is known that a turn must be taken within (forward direction) 300" (+/-10") so that robot avoids hitting a wall. In such a scenario how can we effectively use the SDK signals and drive param to ensure that we are in within threshold ? The idea here is to reduce travel errors once localization is done.

I tried the following approaches:

• always travel by a drive of distanceToCover / originalDistanceToCover. This approach works well in cases where it is required to travel long distances like 124" / 150"
• However this fails when travelling short distances (we need to be driving at a very small speed to being with)
• Another version of above approach, MIN(1, distanceToCover / 27.63") This magic number corresponds to the approx circumference of the wheel..

I guess I need to do something like a slow start .. steady speed ... slow stop, to ensure that the error between the actual and expected travel distances is minimal.

The drive and variableDrive values passed to the drive:turn: and variableDrive:turn: methods are the target speed. You must call one of those methods in the doubleDriveShouldUpdate: callback because that callback fires before each time it sends a drive command to the base. For safety, it defaults to 0 each time, unless you call drive:turn: or variableDrive:turn: within that callback.

The robot will ramp up to the target speed. For variableDrive:turn:, a value of 1.0 is essentially "100% of normal speed forward", -1.0 is "100% of normal speed backwards" (but the "normal" backwards speed is less than half of normal forward speed. Due to the natural balancing motion of the robot, it will need to slow down before coming to a complete stop.

If you're looking to target a specific end point, you'll need to predict the distance that the robot will require to come to a complete stop, since you have control of only speed. This distance can vary based on the environment, of course, but it should be somewhat consistent on a flat surface.

I agree that slowing down using smaller drive values passed to variableDrive:turn: as the robot reaches its target should enable you to have more precise control of the end point.

Let us know if you get it working well enough for your application.