Odometry

Odometry motion profiling

Need for odometry

To create autons quicker and go farther more accurately we will need to know our position on the field.

Requirements for odometry:

• Acurite over a 1 minute period
• Non intrusive on other robot subsystems
• Able to update fast enough to maintain an accurate position with complex and high speed movements

Types of odometry:

All of these types of odometry can be useful in different situations and can be used together

• VEX Game Positioning Sensor
  • Pros:
    • Implementation already done for you
    • Non intrusive, only a small sensor
    • According to @jpearman(One of VEX Engineers) on the vex forums it is extremely fast and accurate.
  • Cons:
    • If camera is blocked you lose your position
    • You will probably have to implement some other position tracker to keep driving if the sensor is blocked.
    • Has to have solid view of field
    • Expensive
    • Only works on Skills fields, because it is only required on those fields
• Vision odometry
  • Pros:
    • Works well when need accurate position relative to a field element
    • Only need vision sensor
    • Implementations can be simple
    • Good vision sensor targets on moving game elements
  • Cons:
    • VEX Vision system has slow update time limiting speed
    • Low accuracy and very jumpy
    • Loses track of position when far away from target
    • Not many stationary vision targets on the field
• Accelerometer dead reckoning
  • Pros:
    • Extremely unintrusive
    • Not dependent on robot hardware
    • Easy to implement
  • Cons:
    • Needs fast update time
    • Drift acculilates really fast
    • Loses accuracy over time at unusable rates
    • Loses accuracy with high acceleration and high speed motions
• Wheel dead reckoning
  • Pros:
    • Position is accurate and fast updating
    • Can have very small update cycles and still have fast updates
    • Multiple implementations with different use cases
    • Very flexible implementations
  • Cons:
    • Relative to starting position and isn’t entirely representative of position on field (starting position of robot might be different from what the robot “Thinks” it is at)
    • If using drive wheels position can be lost in fast accelerations

Right now we do not have access to a VEX Game Positioning sensor or adequate field modifications to use it so that option is off the table for this revision of the software. Of the remaining options, wheel dead reckoning is the best solution to use in general because of the reliable position tracking and speed of estimates.

Implementation of wheel dead reckoning

Goal

Choose a wheel dead reckoning

As we are using a holonomic drive we need to have full 2 dimensional odometry, this means that our main options are the following.

Holonomic odometry options

• Mecanum inverse kinematics
  • Pros:
    • Non intrusive
    • If using IMU, maintains orientation if slippage occurs
  • Cons:
    • Most difficult implement
    • Loses position if wheels slip while accelerating
    • Harder to program
    • Implementation is less accurate
• Two wheel
  • Pros:
    • Easiest to implement
    • Maintains orientation even if wheel slippage occurs
    • Less intrusive, 2 dead wheels vs 3
    • Uses existing IMU
    • Dead wheels don’t drift
  • Cons:
    • Needs IMU operational - IMU takes about 3 seconds to calibrate at the beginning of auton
    • IMU drifts over time so positional estimates become less accurate.
    • Loses orientation in fast, jerky moves with high acceleration
    • Loses accuracy over time
    • Sensitive to orientation changes
    • Needs dead wheels
• Three wheel odometry:
  • Pros:
    • Maintains fair accuracy over time
    • Don’t need IMU
    • Accurate and fast
    • Update cycles can be faster than other methods
    • Dead wheels don’t drift
  • Cons:
    • 3 wheels instead of 2, more intrusive
    • Position is not quite fluid as all of the dead wheels have minimum increments
    • Needs dead wheels