More error at lower rotation rate (Turn in place)

RMP 210, 220, 440LE, 440SE, 440 Omni
Post Reply
aayoade
Posts: 1
Joined: Mon Jul 08, 2013 7:32 pm

More error at lower rotation rate (Turn in place)

Post by aayoade »

Hi,
We carried out some turn rate experiment on the RMP 440LE and I have attached some of the results which include the plot of estimated pse_yaw_rate, inertial_z_rate, diff_wheel_vel against time.
We noticed some abnormal behavior in which we have more error at lower rotation rate. Unlike the other measured variables, the estimated pse_yaw_rate (from the RMP response data) dissipated over time at lower turn rate.
It should be noted that the experiment was carried out on a level floor.


Has anyone noticed this behavior?
Could Segway comment on why we see a difference(more error) at lower rotation rate?
Also, we have other data sets if you would like to look at them.
In addition, we have also noticed a latency of about 0.15s between command and the RMP response (Any Comment?)

The experiment was done at different turn rate with following parameter settings:
MAX_TURN_ACCELERATION=28.274rad/s^2
MAX_TURN_RATE=3.142rad/s
Normalized yaw rate = 0.17 and 0.33 (equivalent of 30deg/s and 60deg/s)
You do not have the required permissions to view the files attached to this post.

phussey
Posts: 79
Joined: Fri Apr 20, 2012 8:12 am

Re: More error at lower rotation rate (Turn in place)

Post by phussey »

There are a few answers to your questions:

1. RMP 440 is a skid steer vehicle so the odometry data (diff_wheel_vel_rps) is purely the differential velocity between the wheels and depending on things like surface traction, payload, rates etc the value will vary from the inertial data.

2. The PSE yaw rate is the yaw rate output from the inertial state estimator used by Segway's balancing platforms and the PT. It is designed to correct for gyro bias drift based on the odometry feedback. Because the RMP440 differential wheel velocity cannot be correlated to vehicle yaw rate, the data cannot be used to correct the gyro bias drift at the input to the PSE. What you are seeing at low yaw rates is the bias drift effecting the estimator more significantly because the bias makes up more of the signal magnitude fed into the estimator. At higher rates this will take longer but will still cause the output to diverge over time. When the platform stops moving the PSE yaw rate output will converge back to zero.

Long story short the value can be used for short periods of time, but will tend to drift to varying degrees over time depending on the physical gyro characteristics and the magnitude of the vehicle yaw rate in relation to the bias. It is useful to get body yaw rate in the inertial frame when not on a level surface for short periods of time.

3. The raw inertial yaw rate is the temperature corrected output of the yaw axis gyro sensors. For the 440 this is generally the best piece of information to use to determine the actual vehicle yaw rate. It will however require some sort of external correction such as a OTC e-compass (alternatively found in many handheld devices, computers and GPS now), or just bias sampling by the external system when the platform is not in motion to correct for variance in bias drift.

Last option is to use a OTC IMU such as http://www.microstrain.com/inertial/3DM-GX3-25, which has all of the temperature and bias correction built in. This is useful for high precision autonomous applications where the accuracy is needed.


The last question about the latency:

The RMP application runs at 100Hz (executing a frame every 0.01s). The longest latency should be 0.01s if the communication is received the instant after communications are processed from the host. You should see the effects of the command in the feedback data the next frame after it is processed and executed by the application (0.02s). The only thing I can think of is that if you are using USB there may be some latency due its lack of robustness for real time communication, although the protocol is fast any windows and non RT linux are not real-time.

So there are two options:
1. Update the host hardware to real-time hardware and software
2. Use CAN to communicate with the platform and use the timestamp in the buffer.

Hopefully this helps answer your questions.
PATRICK HUSSEY
Principal Engineer

STANLEY INNOVATION, INC
www.stanleyinnovation.com

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests