The gyro on the power board provides input to the "user analog input" pin on the Create. Your Windows API will likely provide a method for reading this. If it doesn't, check out this document.
The next step you'll have is to correct for sensor error. There are two primary types you should worry about:
- Scale error. The gyro may provide an analog value for a given rotational rate which doesn't quite match up with the spec. The turtlebot_calibration node can automatically determine this error by comparing a prediction based on the gyro with an actual observation of motion from the TurtleBot's Kinect sensor.
- Drift. The analog value corresponding to a zero rotational rate drifts over time. The TurtleBot is constantly recalibrating what the "zero value" is by averaging gyro sensor values when both wheels are not moving, and using that value as an offset.
After you do those two corrections, you're left with incorporating that data into your position estimates. You can start by integrating it to determine chassis rotation in your current dead-reckoning approach, and improve it further by adding Kinect data via an extended Kalman Filter. I'm not sure what direction you want to go in for this latter point, but hopefully the above helps...1.
Originally posted by Ryan with karma: 3248 on 2012-03-10
This answer was ACCEPTED on the original site
Post score: 4
Original comments
Comment by Mac on 2012-03-10:
I second all of the above; at this point, though, you've just reinvented a bunch of stuff that ROS does for you, in a well-debugged, well-integrated manner. I'm told there's some rudimentary ROS support on windows; probably enough to let a linux machine do the work, and a windows do the controls.
